Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix scheduling with atomic in timestamp sockopt<br /> <br /> Using lock_sock_fast() (atomic context) around sock_set_timestamp()<br /> and sock_set_timestamping() is unsafe, as both helpers can sleep.<br /> <br /> Replace lock_sock_fast() with sleepable lock_sock()/release_sock()<br /> to avoid scheduling while atomic panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: kvm: fix vector context allocation leak<br /> <br /> When the second kzalloc (host_context.vector.datap) fails in<br /> kvm_riscv_vcpu_alloc_vector_context, the first allocation<br /> (guest_context.vector.datap) is leaked. Free it before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: ADD_ADDR rtx: free sk if last<br /> <br /> When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(),<br /> and released at the end.<br /> <br /> If at that moment, it was the last reference being held, the sk would<br /> not be freed. sock_put() should then be called instead of __sock_put().<br /> <br /> But that&amp;#39;s not enough: if it is the last reference, sock_put() will call<br /> sk_free(), which will end up calling sk_stop_timer_sync() on the same<br /> timer, and waiting indefinitely to finish. So it is needed to mark that<br /> the timer is done at the end of the timer handler when it has not been<br /> rescheduled, not to call sk_stop_timer_sync() on "itself".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free in create_space_info_sub_group() error path<br /> <br /> When kobject_init_and_add() fails, the call chain is:<br /> <br /> create_space_info_sub_group()<br /> -&gt; btrfs_sysfs_add_space_info_type()<br /> -&gt; kobject_init_and_add()<br /> -&gt; failure<br /> -&gt; kobject_put(&amp;sub_group-&gt;kobj)<br /> -&gt; space_info_release()<br /> -&gt; kfree(sub_group)<br /> <br /> Then control returns to create_space_info_sub_group(), where:<br /> <br /> btrfs_sysfs_add_space_info_type() returns error<br /> -&gt; kfree(sub_group)<br /> <br /> Thus, sub_group is freed twice.<br /> <br /> Keep parent-&gt;sub_group[index] = NULL for the failure path, but after<br /> btrfs_sysfs_add_space_info_type() has called kobject_put(), let the<br /> kobject release callback handle the cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix uninit-value by validating catalog record size<br /> <br /> Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The<br /> root cause is that hfs_brec_read() doesn&amp;#39;t validate that the on-disk<br /> record size matches the expected size for the record type being read.<br /> <br /> When mounting a corrupted filesystem, hfs_brec_read() may read less data<br /> than expected. For example, when reading a catalog thread record, the<br /> debug output showed:<br /> <br /> HFSPLUS_BREC_READ: rec_len=520, fd-&gt;entrylength=26<br /> HFSPLUS_BREC_READ: WARNING - entrylength (26)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: use safe list iteration in radar detect work<br /> <br /> The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to<br /> be freed and removed from the list. Guard against this to avoid a<br /> slab-use-after-free error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters<br /> <br /> scx_group_set_{weight,idle,bandwidth}() cache scx_root before acquiring<br /> scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs.<br /> If the loaded scheduler is disabled and freed (via RCU work) and another is<br /> enabled between the naked load and the rwsem acquire, the reader sees<br /> scx_cgroup_enabled=true (the new scheduler&amp;#39;s) but dereferences the freed one<br /> - UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...).<br /> <br /> scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write<br /> (scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section<br /> correlates @sch with the enabled snapshot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()<br /> <br /> The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and<br /> readl(crtc_reg) will access with random address, because the "device" is<br /> from "base+PCI_DEVICE_ID", "base" is from "pdev-&gt;devfn+1". This is wrong<br /> when my platform inserts a discrete GPU:<br /> <br /> lspci -tv<br /> -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller<br /> ...<br /> +-06.0 Loongson Technology LLC LG100 GPU<br /> +-06.2 Loongson Technology LLC Device 7a37<br /> ...<br /> <br /> Add a default switch case to fix the panic as below:<br /> <br /> Kernel ade access[#1]:<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4<br /> pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0<br /> a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002<br /> a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001<br /> t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000<br /> t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0<br /> t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8<br /> s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000<br /> s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000<br /> ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210<br /> ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1)<br /> BADV: 7fffffffffffff00<br /> PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)<br /> Modules linked in:<br /> Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____))<br /> Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007<br /> 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff<br /> 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08<br /> 0000000000000000 0000000000000000 0000000000000006 90000001002fb778<br /> 90000001000530b8 90000000027af000 0000000000000000 9000000100054000<br /> 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001<br /> 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000<br /> 0000000000000006 90000000027af000 0000000000000030 90000000027af000<br /> 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560<br /> 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030<br /> ...<br /> Call Trace:<br /> [] loongson_gpu_fixup_dma_hang+0xb4/0x210<br /> [] pci_fixup_device+0x108/0x280<br /> [] pci_setup_device+0x24c/0x690<br /> [] pci_scan_single_device+0xe0/0x140<br /> [] pci_scan_slot+0xc4/0x280<br /> [] pci_scan_child_bus_extend+0x60/0x3f0<br /> [] acpi_pci_root_create+0x2b4/0x420<br /> [] pci_acpi_scan_root+0x2d4/0x440<br /> [] acpi_pci_root_add+0x21c/0x3a0<br /> [] acpi_bus_attach+0x1a4/0x3c0<br /> [] device_for_each_child+0x6c/0xe0<br /> [] acpi_dev_for_each_child+0x44/0x70<br /> [] acpi_bus_attach+0x290/0x3c0<br /> [] device_for_each_child+0x6c/0xe0<br /> [] acpi_dev_for_each_child+0x44/0x70<br /> [] acpi_bus_attach+0x290/0x3c0<br /> [] acpi_bus_scan+0x6c/0x280<br /> [] acpi_scan_init+0x194/0x310<br /> [] acpi_init+0xcc/0x140<br /> [] do_one_initcall+0x4c/0x310<br /> [] kernel_init_freeable+0x258/0x2d4<br /> [] kernel_init+0x28/0x13c<br /> [] ret_from_kernel_thread+0xc/0xa4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger<br /> <br /> Currently the runtime.oss.trigger field may be accessed concurrently<br /> without protection, which may lead to the data race. And, in this<br /> case, it may lead to more severe problem because it&amp;#39;s a bit field; as<br /> writing the data, it may overwrite other bit fields as well, which<br /> confuses the operation completely, as spotted by fuzzing.<br /> <br /> Fix it by covering runtime.oss.trigger bit fled also with the existing<br /> params_lock mutex in both snd_pcm_oss_get_trigger() and<br /> snd_pcm_oss_poll().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: ADD_ADDR rtx: always decrease sk refcount<br /> <br /> When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer().<br /> It should then be released in all cases at the end.<br /> <br /> Some (unlikely) checks were returning directly instead of calling<br /> sock_put() to decrease the refcount. Jump to a new &amp;#39;exit&amp;#39; label to call<br /> __sock_put() (which will become sock_put() in the next commit) to fix<br /> this potential leak.<br /> <br /> While at it, drop the &amp;#39;!msk&amp;#39; check which cannot happen because it is<br /> never reset, and explicitly mark the remaining one as "unlikely".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix out-of-bounds read in smb2_compound_op()<br /> <br /> If a server sends a truncated response but a large OutputBufferLength, and<br /> terminates the EA list early, check_wsl_eas() returns success without<br /> validating that the entire OutputBufferLength fits within iov_len.<br /> <br /> Then smb2_compound_op() does:<br /> memcpy(idata-&gt;wsl.eas, data[0], size[0]);<br /> <br /> Where size[0] is OutputBufferLength. If iov_len is smaller than size[0],<br /> memcpy can read beyond the end of the rsp_iov allocation and leak adjacent<br /> kernel heap memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix divide-by-zero in setup_geo() with zero far_copies<br /> <br /> setup_geo() extracts near_copies (nc) and far_copies (fc) from the<br /> user-provided layout parameter without checking for zero. When fc=0<br /> with the "improved" far set layout selected, &amp;#39;geo-&gt;far_set_size =<br /> disks / fc&amp;#39; triggers a divide-by-zero.<br /> <br /> Validate nc and fc immediately after extraction, returning -1 if<br /> either is zero.