Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: catc: enable basic endpoint checking<br /> <br /> catc_probe() fills three URBs with hardcoded endpoint pipes without<br /> verifying the endpoint descriptors:<br /> <br /> - usb_sndbulkpipe(usbdev, 1) and usb_rcvbulkpipe(usbdev, 1) for TX/RX<br /> - usb_rcvintpipe(usbdev, 2) for interrupt status<br /> <br /> A malformed USB device can present these endpoints with transfer types<br /> that differ from what the driver assumes.<br /> <br /> Add a catc_usb_ep enum for endpoint numbers, replacing magic constants<br /> throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints()<br /> calls after usb_set_interface() to verify endpoint types before use,<br /> rejecting devices with mismatched descriptors at probe time.<br /> <br /> Similar to<br /> - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking")<br /> which fixed the issue in rtl8150.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handler<br /> <br /> The UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) function<br /> allocates memory for the device path using kobject_get_path(). If the<br /> length of the device path exceeds the output buffer length, the function<br /> returns -ENOSPC but does not free the allocated memory, resulting in a<br /> memory leak.<br /> <br /> Add a kfree() call to the error path to ensure the allocated memory is<br /> properly freed.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse()<br /> <br /> The function mtd_parser_tplink_safeloader_parse() allocates buf via<br /> mtd_parser_tplink_safeloader_read_table(). If the allocation for<br /> parts[idx].name fails inside the loop, the code jumps to the err_free<br /> label without freeing buf, leading to a memory leak.<br /> <br /> Fix this by freeing the temporary buffer buf in the err_free label.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "hwmon: (ibmpex) fix use-after-free in high/low store"<br /> <br /> This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.<br /> <br /> Jean Delvare points out that the patch does not completely<br /> fix the reported problem, that it in fact introduces a<br /> (new) race condition, and that it may actually not be needed in<br /> the first place.<br /> <br /> Various AI reviews agree. Specific and relevant AI feedback:<br /> <br /> "<br /> This reordering sets the driver data to NULL before removing the sensor<br /> attributes in the loop below.<br /> <br /> ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but<br /> does not check if it is NULL before dereferencing it to access<br /> data-&gt;sensors[].<br /> <br /> If a userspace process reads a sensor file (like temp1_input) while this<br /> delete function is running, could it race with the dev_set_drvdata(...,<br /> NULL) call here and crash in ibmpex_show_sensor()?<br /> <br /> Would it be safer to keep the original order where device_remove_file() is<br /> called before clearing the driver data? device_remove_file() should wait<br /> for any active sysfs callbacks to complete, which might already prevent the<br /> use-after-free this patch intends to fix.<br /> "<br /> <br /> Revert the offending patch. If it can be shown that the originally reported<br /> alleged race condition does indeed exist, it can always be re-introduced<br /> with a complete fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mcast: always update mdb_n_entries for vlan contexts<br /> <br /> syzbot triggered a warning[1] about the number of mdb entries in a context.<br /> It turned out that there are multiple ways to trigger that warning today<br /> (some got added during the years), the root cause of the problem is that<br /> the increase is done conditionally, and over the years these different<br /> conditions increased so there were new ways to trigger the warning, that is<br /> to do a decrease which wasn&amp;#39;t paired with a previous increase.<br /> <br /> For example one way to trigger it is with flush:<br /> $ ip l add br0 up type bridge vlan_filtering 1 mcast_snooping 1<br /> $ ip l add dumdum up master br0 type dummy<br /> $ bridge mdb add dev br0 port dumdum grp 239.0.0.1 permanent vid 1<br /> $ ip link set dev br0 down<br /> $ ip link set dev br0 type bridge mcast_vlan_snooping 1<br /> ^^^^ this will enable snooping, but will not update mdb_n_entries<br /> because in __br_multicast_enable_port_ctx() we check !netif_running<br /> $ bridge mdb flush dev br0<br /> ^^^ this will trigger the warning because it will delete the pg which<br /> we added above, which will try to decrease mdb_n_entries<br /> <br /> Fix the problem by removing the conditional increase and always keep the<br /> count up-to-date while the vlan exists. In order to do that we have to<br /> first initialize it on port-vlan context creation, and then always increase<br /> or decrease the value regardless of mcast options. To keep the current<br /> behaviour we have to enforce the mdb limit only if the context is port&amp;#39;s or<br /> if the port-vlan&amp;#39;s mcast snooping is enabled.<br /> <br /> [1]<br /> ------------[ cut here ]------------<br /> n == 0<br /> WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline], CPU#0: syz.4.4607/22043<br /> WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline], CPU#0: syz.4.4607/22043<br /> WARNING: net/bridge/br_multicast.c:718 at br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825, CPU#0: syz.4.4607/22043<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 22043 Comm: syz.4.4607 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026<br /> RIP: 0010:br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline]<br /> RIP: 0010:br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline]<br /> RIP: 0010:br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825<br /> Code: 41 5f 5d e9 04 7a 48 f7 e8 3f 73 5c f7 90 0f 0b 90 e9 cf fd ff ff e8 31 73 5c f7 90 0f 0b 90 e9 16 fd ff ff e8 23 73 5c f7 90 0b 90 e9 60 fd ff ff e8 15 73 5c f7 eb 05 e8 0e 73 5c f7 48 8b<br /> RSP: 0018:ffffc9000c207220 EFLAGS: 00010293<br /> RAX: ffffffff8a68042d RBX: ffff88807c6f1800 RCX: ffff888066e90000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: ffff888066e90000 R09: 000000000000000c<br /> R10: 000000000000000c R11: 0000000000000000 R12: ffff8880303ef800<br /> R13: dffffc0000000000 R14: ffff888050eb11c4 R15: 1ffff1100a1d6238<br /> FS: 00007fa45921b6c0(0000) GS:ffff8881256f5000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa4591f9ff8 CR3: 0000000081df2000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> br_mdb_flush_pgs net/bridge/br_mdb.c:1525 [inline]<br /> br_mdb_flush net/bridge/br_mdb.c:1544 [inline]<br /> br_mdb_del_bulk+0x5e2/0xb20 net/bridge/br_mdb.c:1561<br /> rtnl_mdb_del+0x48a/0x640 net/core/rtnetlink.c:-1<br /> rtnetlink_rcv_msg+0x77e/0xbe0 net/core/rtnetlink.c:6967<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_sendmsg+0x2a5/0x360 net/socke<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix dirtyclusters double decrement on fs shutdown<br /> <br /> fstests test generic/388 occasionally reproduces a warning in<br /> ext4_put_super() associated with the dirty clusters count:<br /> <br /> WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]<br /> <br /> Tracing the failure shows that the warning fires due to an<br /> s_dirtyclusters_counter value of -1. IOW, this appears to be a<br /> spurious decrement as opposed to some sort of leak. Further tracing<br /> of the dirty cluster count deltas and an LLM scan of the resulting<br /> output identified the cause as a double decrement in the error path<br /> between ext4_mb_mark_diskspace_used() and the caller<br /> ext4_mb_new_blocks().<br /> <br /> First, note that generic/388 is a shutdown vs. fsstress test and so<br /> produces a random set of operations and shutdown injections. In the<br /> problematic case, the shutdown triggers an error return from the<br /> ext4_handle_dirty_metadata() call(s) made from<br /> ext4_mb_mark_context(). The changed value is non-zero at this point,<br /> so ext4_mb_mark_diskspace_used() does not exit after the error<br /> bubbles up from ext4_mb_mark_context(). Instead, the former<br /> decrements both cluster counters and returns the error up to<br /> ext4_mb_new_blocks(). The latter falls into the !ar-&gt;len out path<br /> which decrements the dirty clusters counter a second time, creating<br /> the inconsistency.<br /> <br /> To avoid this problem and simplify ownership of the cluster<br /> reservation in this codepath, lift the counter reduction to a single<br /> place in the caller. This makes it more clear that<br /> ext4_mb_new_blocks() is responsible for acquiring cluster<br /> reservation (via ext4_claim_free_clusters()) in the !delalloc case<br /> as well as releasing it, regardless of whether it ends up consumed<br /> or returned due to failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Skip currently executing CPU in rto_next_cpu()<br /> <br /> CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound<br /> RT task, and a CFS task stuck in kernel space. When other CPUs switch from<br /> RT to non-RT tasks, RT load balancing (LB) is triggered; with<br /> HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution<br /> of rto_push_irq_work_func. During push_rt_task on CPU0,<br /> if next_task-&gt;prio donor-&gt;prio, resched_curr() sets NEED_RESCHED<br /> and after the push operation completes, CPU0 calls rto_next_cpu().<br /> Since only CPU0 is overloaded in this scenario, rto_next_cpu() should<br /> ideally return -1 (no further IPI needed).<br /> <br /> However, multiple CPUs invoking tell_cpu_to_push() during LB increments<br /> rd-&gt;rto_loop_next. Even when rd-&gt;rto_cpu is set to -1, the mismatch between<br /> rd-&gt;rto_loop and rd-&gt;rto_loop_next forces rto_next_cpu() to restart its<br /> search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory<br /> &amp;&amp; rt_nr_total &gt; 1), it gets reselected, causing CPU0 to queue irq_work to<br /> itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and<br /> other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,<br /> which triggers a CPU hardlockup due to continuous self-interrupts.<br /> <br /> The trigging scenario is as follows:<br /> <br /> cpu0 cpu1 cpu2<br /> pull_rt_task<br /> tell_cpu_to_push<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: tcp - don&amp;#39;t deref NULL sk_socket member after tcp_close()<br /> <br /> When deleting a peer in case of keepalive expiration, the peer is<br /> removed from the OpenVPN hashtable and is temporary inserted in a<br /> "release list" for further processing.<br /> <br /> This happens in:<br /> ovpn_peer_keepalive_work()<br /> unlock_ovpn(release_list)<br /> <br /> This processing includes detaching from the socket being used to<br /> talk to this peer, by restoring its original proto and socket<br /> ops/callbacks.<br /> <br /> In case of TCP it may happen that, while the peer is sitting in<br /> the release list, userspace decides to close the socket.<br /> This will result in a concurrent execution of:<br /> <br /> tcp_close(sk)<br /> __tcp_close(sk)<br /> sock_orphan(sk)<br /> sk_set_socket(sk, NULL)<br /> <br /> The last function call will set sk-&gt;sk_socket to NULL.<br /> <br /> When the releasing routine is resumed, ovpn_tcp_socket_detach()<br /> will attempt to dereference sk-&gt;sk_socket to restore its original<br /> ops member. This operation will crash due to sk-&gt;sk_socket being NULL.<br /> <br /> Fix this race condition by testing-and-accessing<br /> sk-&gt;sk_socket atomically under sk-&gt;sk_callback_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: do not keep dest_dst if dev is going down<br /> <br /> There is race between the netdev notifier ip_vs_dst_event()<br /> and the code that caches dst with dev that is going down.<br /> As the FIB can be notified for the closed device after our<br /> handler finishes, it is possible valid route to be returned<br /> and cached resuling in a leaked dev reference until the dest<br /> is not removed.<br /> <br /> To prevent new dest_dst to be attached to dest just after the<br /> handler dropped the old one, add a netif_running() check<br /> to make sure the notifier handler is not currently running<br /> for device that is closing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: sbs-battery: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle. Keep the old behavior of<br /> just printing a warning in case of any failures during the IRQ request<br /> and finishing the probe successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fat: avoid parent link count underflow in rmdir<br /> <br /> Corrupted FAT images can leave a directory inode with an incorrect<br /> i_nlink (e.g. 2 even though subdirectories exist). rmdir then<br /> unconditionally calls drop_nlink(dir) and can drive i_nlink to 0,<br /> triggering the WARN_ON in drop_nlink().<br /> <br /> Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the<br /> parent link count when it is at least 3, otherwise report a filesystem<br /> error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t cache extent during splitting extent<br /> <br /> Caching extents during the splitting process is risky, as it may result<br /> in stale extents remaining in the status tree. Moreover, in most cases,<br /> the corresponding extent block entries are likely already cached before<br /> the split happens, making caching here not particularly useful.<br /> <br /> Assume we have an unwritten extent, and then DIO writes the first half.<br /> <br /> [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUUUUUUUUUUU] extent status tree<br /> || ----&gt; dio write this range<br /> <br /> First, when ext4_split_extent_at() splits this extent, it truncates the<br /> existing extent and then inserts a new one. During this process, this<br /> extent status entry may be shrunk, and calls to ext4_find_extent() and<br /> ext4_cache_extents() may occur, which could potentially insert the<br /> truncated range as a hole into the extent status tree. After the split<br /> is completed, this hole is not replaced with the correct status.<br /> <br /> [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUU|HHHHHHHH] extent status tree H: hole<br /> <br /> Then, the outer calling functions will not correct this remaining hole<br /> extent either. Finally, if we perform a delayed buffer write on this<br /> latter part, it will re-insert the delayed extent and cause an error in<br /> space accounting.<br /> <br /> In adition, if the unwritten extent cache is not shrunk during the<br /> splitting, ext4_cache_extents() also conflicts with existing extents<br /> when caching extents. In the future, we will add checks when caching<br /> extents, which will trigger a warning. Therefore, Do not cache extents<br /> that are being split.