Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exit: prevent preemption of oopsing TASK_DEAD task<br /> <br /> When an already-exiting task oopses, make_task_dead() currently calls<br /> do_task_dead() with preemption enabled. That is forbidden:<br /> do_task_dead() calls __schedule(), which has a comment saying "WARNING:<br /> must be called with preemption disabled!".<br /> <br /> If an oopsing task is preempted in do_task_dead(), between becoming<br /> TASK_DEAD and entering the scheduler explicitly, bad things happen:<br /> finish_task_switch() assumes that once the scheduler has switched away<br /> from a TASK_DEAD task, the task can never run again and its stack is no<br /> longer needed; but that assumption apparently doesn&amp;#39;t hold if the dead<br /> task was preempted (the SM_PREEMPT case).<br /> <br /> This means that the scheduler ends up repeatedly dropping references on<br /> the dead task&amp;#39;s stack, which can lead to use-after-free or double-free<br /> of the entire task stack; in other words, two tasks can end up running<br /> on the same stack, resulting in various kinds of memory corruption.<br /> <br /> (This does not just affect "recursively oopsing" tasks; it is enough to<br /> oops once during task exit, for example in a file_operations::release<br /> handler)

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 /> 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 /> btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak<br /> <br /> btrfs_ioctl_space_info() has a TOCTOU race between two passes over the<br /> block group RAID type lists. The first pass counts entries to determine<br /> the allocation size, then the second pass fills the buffer. The<br /> groups_sem rwlock is released between passes, allowing concurrent block<br /> group removal to reduce the entry count.<br /> <br /> When the second pass fills fewer entries than the first pass counted,<br /> copy_to_user() copies the full alloc_size bytes including trailing<br /> uninitialized kmalloc bytes to userspace.<br /> <br /> Fix by copying only total_spaces entries (the actually-filled count from<br /> the second pass) instead of alloc_size bytes, and switch to kzalloc so<br /> any future copy size mismatch cannot leak heap data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix missing last_unlink_trans update when removing a directory<br /> <br /> When removing a directory we are not updating its last_unlink_trans field,<br /> which can result in incorrect fsync behaviour in case some one fsyncs the<br /> directory after it was removed because it&amp;#39;s holding a file descriptor on<br /> it.<br /> <br /> Example scenario:<br /> <br /> mkdir /mnt/dir1<br /> mkdir /mnt/dir1/dir2<br /> mkdir /mnt/dir3<br /> <br /> sync -f /mnt<br /> <br /> # Do some change to the directory and fsync it.<br /> chmod 700 /mnt/dir1<br /> xfs_io -c fsync /mnt/dir1<br /> <br /> # Move dir2 out of dir1 so that dir1 becomes empty.<br /> mv /mnt/dir1/dir2 /mnt/dir3/<br /> <br /> open fd on /mnt/dir1<br /> call rmdir(2) on path "/mnt/dir1"<br /> fsync fd<br /> <br /> <br /> <br /> When attempting to mount the filesystem, the log replay will fail with<br /> an -EIO error and dmesg/syslog has the following:<br /> <br /> [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650<br /> [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm<br /> [445771.627912] BTRFS info (device dm-0): start tree-log replay<br /> [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5<br /> [445771.629453] memcg:ffff89f400351b00<br /> [445771.629892] aops:btree_aops [btrfs] ino:1<br /> [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)<br /> [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8<br /> [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00<br /> [445771.635029] page dumped because: eb page dump<br /> [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir<br /> [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5<br /> [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087<br /> [445771.638094] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> [445771.638097] inode generation 3 transid 9 size 16 nbytes 16384<br /> [445771.638098] block group 0 mode 40755 links 1 uid 0 gid 0<br /> [445771.638100] rdev 0 sequence 2 flags 0x0<br /> [445771.638102] atime 1775744884.0<br /> [445771.660056] ctime 1775744885.645502983<br /> [445771.660058] mtime 1775744885.645502983<br /> [445771.660060] otime 1775744884.0<br /> [445771.660062] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12<br /> [445771.660064] index 0 name_len 2<br /> [445771.660066] item 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34<br /> [445771.660068] location key (259 1 0) type 2<br /> [445771.660070] transid 9 data_len 0 name_len 4<br /> [445771.660075] item 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34<br /> [445771.660076] location key (257 1 0) type 2<br /> [445771.660077] transid 9 data_len 0 name_len 4<br /> [445771.660078] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34<br /> [445771.660079] location key (257 1 0) type 2<br /> [445771.660080] transid 9 data_len 0 name_len 4<br /> [445771.660081] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34<br /> [445771.660082] location key (259 1 0) type 2<br /> [445771.660083] transid 9 data_len 0 name_len 4<br /> [445771.660084] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160<br /> [445771.660086] inode generation 9 transid 9 size 8 nbytes 0<br /> [445771.660087] block group 0 mode 40777 links 1 uid 0 gid 0<br /> [445771.660088] rdev 0 sequence 2 flags 0x0<br /> [445771.660089] atime 1775744885.641174097<br /> [445771.660090] ctime 1775744885.645502983<br /> [445771.660091] mtime 1775744885.645502983<br /> [445771.660105] otime 1775744885.641174097<br /> [445771.660106] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14<br /> [445771.660107] index 2 name_len 4<br /> [445771.660108] item 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34<br /> [445771.660109] location key (2<br /> ---truncated---

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix double free in ice_sf_eth_activate() error path<br /> <br /> When auxiliary_device_add() fails, ice_sf_eth_activate() jumps to<br /> aux_dev_uninit and calls auxiliary_device_uninit(&amp;sf_dev-&gt;adev).<br /> <br /> The device release callback ice_sf_dev_release() frees sf_dev, but<br /> the current error path falls through to sf_dev_free and calls<br /> kfree(sf_dev) again, causing a double free.<br /> <br /> Keep kfree(sf_dev) for the auxiliary_device_init() failure path, but<br /> avoid falling through to sf_dev_free after auxiliary_device_uninit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: b43legacy: enforce bounds check on firmware key index in RX path<br /> <br /> Same fix as b43: the firmware-controlled key index in b43legacy_rx()<br /> can exceed dev-&gt;max_nr_keys. The existing B43legacy_WARN_ON is<br /> non-enforcing in production builds, allowing an out-of-bounds read of<br /> dev-&gt;key[].<br /> <br /> Make the check enforcing by dropping the frame for invalid indices.

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 /> 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 /> 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 /> RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()<br /> <br /> Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal<br /> destroy path cleans it up.