Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix readahead reclaim deadlock<br /> <br /> Commit e26ee4efbc79 ("fuse: allocate ff-&gt;release_args only if release is<br /> needed") skips allocating ff-&gt;release_args if the server does not<br /> implement open. However in doing so, fuse_prepare_release() now skips<br /> grabbing the reference on the inode, which makes it possible for an<br /> inode to be evicted from the dcache while there are inflight readahead<br /> requests. This causes a deadlock if the server triggers reclaim while<br /> servicing the readahead request and reclaim attempts to evict the inode<br /> of the file being read ahead. Since the folio is locked during<br /> readahead, when reclaim evicts the fuse inode and fuse_evict_inode()<br /> attempts to remove all folios associated with the inode from the page<br /> cache (truncate_inode_pages_range()), reclaim will block forever waiting<br /> for the lock since readahead cannot relinquish the lock because it is<br /> itself blocked in reclaim:<br /> <br /> &gt;&gt;&gt; stack_trace(1504735)<br /> folio_wait_bit_common (mm/filemap.c:1308:4)<br /> folio_lock (./include/linux/pagemap.h:1052:3)<br /> truncate_inode_pages_range (mm/truncate.c:336:10)<br /> fuse_evict_inode (fs/fuse/inode.c:161:2)<br /> evict (fs/inode.c:704:3)<br /> dentry_unlink_inode (fs/dcache.c:412:3)<br /> __dentry_kill (fs/dcache.c:615:3)<br /> shrink_kill (fs/dcache.c:1060:12)<br /> shrink_dentry_list (fs/dcache.c:1087:3)<br /> prune_dcache_sb (fs/dcache.c:1168:2)<br /> super_cache_scan (fs/super.c:221:10)<br /> do_shrink_slab (mm/shrinker.c:435:9)<br /> shrink_slab (mm/shrinker.c:626:10)<br /> shrink_node (mm/vmscan.c:5951:2)<br /> shrink_zones (mm/vmscan.c:6195:3)<br /> do_try_to_free_pages (mm/vmscan.c:6257:3)<br /> do_swap_page (mm/memory.c:4136:11)<br /> handle_pte_fault (mm/memory.c:5562:10)<br /> handle_mm_fault (mm/memory.c:5870:9)<br /> do_user_addr_fault (arch/x86/mm/fault.c:1338:10)<br /> handle_page_fault (arch/x86/mm/fault.c:1481:3)<br /> exc_page_fault (arch/x86/mm/fault.c:1539:2)<br /> asm_exc_page_fault+0x22/0x27<br /> <br /> Fix this deadlock by allocating ff-&gt;release_args and grabbing the<br /> reference on the inode when preparing the file for release even if the<br /> server does not implement open. The inode reference will be dropped when<br /> the last reference on the fuse file is dropped (see fuse_file_put() -&gt;<br /> fuse_release_end()).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: alps - fix use-after-free bugs caused by dev3_register_work<br /> <br /> The dev3_register_work delayed work item is initialized within<br /> alps_reconnect() and scheduled upon receipt of the first bare<br /> PS/2 packet from an external PS/2 device connected to the ALPS<br /> touchpad. During device detachment, the original implementation<br /> calls flush_workqueue() in psmouse_disconnect() to ensure<br /> completion of dev3_register_work. However, the flush_workqueue()<br /> in psmouse_disconnect() only blocks and waits for work items that<br /> were already queued to the workqueue prior to its invocation. Any<br /> work items submitted after flush_workqueue() is called are not<br /> included in the set of tasks that the flush operation awaits.<br /> This means that after flush_workqueue() has finished executing,<br /> the dev3_register_work could still be scheduled. Although the<br /> psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),<br /> the scheduling of dev3_register_work remains unaffected.<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (cleanup path) | CPU 1 (delayed work)<br /> psmouse_disconnect() |<br /> psmouse_set_state() |<br /> flush_workqueue() | alps_report_bare_ps2_packet()<br /> alps_disconnect() | psmouse_queue_work()<br /> kfree(priv); // FREE | alps_register_bare_ps2_mouse()<br /> | priv = container_of(work...); // USE<br /> | priv-&gt;dev3 // USE<br /> <br /> Add disable_delayed_work_sync() in alps_disconnect() to ensure<br /> that dev3_register_work is properly canceled and prevented from<br /> executing after the alps_data structure has been deallocated.<br /> <br /> This bug is identified by static analysis.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency<br /> <br /> Under high concurrency, A tree-connection object (tcon) is freed on<br /> a disconnect path while another path still holds a reference and later<br /> executes *_put()/write on it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: vfs: fix race on m_flags in vfs_cache<br /> <br /> ksmbd maintains delete-on-close and pending-delete state in<br /> ksmbd_inode-&gt;m_flags. In vfs_cache.c this field is accessed under<br /> inconsistent locking: some paths read and modify m_flags under<br /> ci-&gt;m_lock while others do so without taking the lock at all.<br /> <br /> Examples:<br /> <br /> - ksmbd_query_inode_status() and __ksmbd_inode_close() use<br /> ci-&gt;m_lock when checking or updating m_flags.<br /> - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()<br /> used to read and modify m_flags without ci-&gt;m_lock.<br /> <br /> This creates a potential data race on m_flags when multiple threads<br /> open, close and delete the same file concurrently. In the worst case<br /> delete-on-close and pending-delete bits can be lost or observed in an<br /> inconsistent state, leading to confusing delete semantics (files that<br /> stay on disk after delete-on-close, or files that disappear while still<br /> in use).<br /> <br /> Fix it by:<br /> <br /> - Making ksmbd_query_inode_status() look at m_flags under ci-&gt;m_lock<br /> after dropping inode_hash_lock.<br /> - Adding ci-&gt;m_lock protection to all helpers that read or modify<br /> m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).<br /> - Keeping the existing ci-&gt;m_lock protection in __ksmbd_inode_close(),<br /> and moving the actual unlink/xattr removal outside the lock.<br /> <br /> This unifies the locking around m_flags and removes the data race while<br /> preserving the existing delete-on-close behaviour.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslot<br /> <br /> Reject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that was<br /> initially created with a guest_memfd binding, as KVM doesn&amp;#39;t support<br /> toggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enabling<br /> KVM_MEM_GUEST_MEMFD, but doesn&amp;#39;t prevent clearing the flag.<br /> <br /> Failure to reject the new memslot results in a use-after-free due to KVM<br /> not unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLY<br /> change is easy enough, and can/will be done as a hardening measure (in<br /> anticipation of KVM supporting dirty logging on guest_memfd at some point),<br /> but fixing the use-after-free would only address the immediate symptom.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm]<br /> Write of size 8 at addr ffff8881111ae908 by task repro/745<br /> <br /> CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xcb/0x5c0<br /> kasan_report+0xb4/0xe0<br /> kvm_gmem_release+0x362/0x400 [kvm]<br /> __fput+0x2fa/0x9d0<br /> task_work_run+0x12c/0x200<br /> do_exit+0x6ae/0x2100<br /> do_group_exit+0xa8/0x230<br /> __x64_sys_exit_group+0x3a/0x50<br /> x64_sys_call+0x737/0x740<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f581f2eac31<br /> <br /> <br /> Allocated by task 745 on cpu 6 at 9.746971s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_kmalloc+0x77/0x90<br /> kvm_set_memory_region.part.0+0x652/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 745 on cpu 6 at 9.747467s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_save_free_info+0x37/0x50<br /> __kasan_slab_free+0x3b/0x60<br /> kfree+0xf5/0x440<br /> kvm_set_memslot+0x3c2/0x1160 [kvm]<br /> kvm_set_memory_region.part.0+0x86a/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: use rc_pageoff for memcpy byte offset<br /> <br /> svc_rdma_copy_inline_range added rc_curpage (page index) to the page<br /> base instead of the byte offset rc_pageoff. Use rc_pageoff so copies<br /> land within the current page.<br /> <br /> Found by ZeroPath (https://zeropath.com)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix ipv4 null-ptr-deref in route error path<br /> <br /> The IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()<br /> without ensuring skb-&gt;dev is set, leading to a NULL pointer dereference<br /> in fib_compute_spec_dst() when ipv4_link_failure() attempts to send<br /> ICMP destination unreachable messages.<br /> <br /> The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options<br /> in ipv4_link_failure") started calling __ip_options_compile() from<br /> ipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()<br /> which dereferences skb-&gt;dev. An attempt was made to fix the NULL skb-&gt;dev<br /> dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in<br /> ipv4_link_failure"), but it only addressed the immediate dev_net(skb-&gt;dev)<br /> dereference by using a fallback device. The fix was incomplete because<br /> fib_compute_spec_dst() later in the call chain still accesses skb-&gt;dev<br /> directly, which remains NULL when IPVS calls dst_link_failure().<br /> <br /> The crash occurs when:<br /> 1. IPVS processes a packet in NAT mode with a misconfigured destination<br /> 2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route<br /> 3. The error path calls dst_link_failure(skb) with skb-&gt;dev == NULL<br /> 4. ipv4_link_failure() → ipv4_send_dest_unreach() →<br /> __ip_options_compile() → fib_compute_spec_dst()<br /> 5. fib_compute_spec_dst() dereferences NULL skb-&gt;dev<br /> <br /> Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix<br /> ipv6 route unreach panic"): set skb-&gt;dev from skb_dst(skb)-&gt;dev before<br /> calling dst_link_failure().<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]<br /> CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2<br /> RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233<br /> RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285<br /> Call Trace:<br /> <br /> spec_dst_fill net/ipv4/ip_options.c:232<br /> spec_dst_fill net/ipv4/ip_options.c:229<br /> __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330<br /> ipv4_send_dest_unreach net/ipv4/route.c:1252<br /> ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265<br /> dst_link_failure include/net/dst.h:437<br /> __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412<br /> ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix filename leak in __io_openat_prep()<br /> <br /> __io_openat_prep() allocates a struct filename using getname(). However,<br /> for the condition of the file being installed in the fixed file table as<br /> well as having O_CLOEXEC flag set, the function returns early. At that<br /> point, the request doesn&amp;#39;t have REQ_F_NEED_CLEANUP flag set. Due to this,<br /> the memory for the newly allocated struct filename is not cleaned up,<br /> causing a memory leak.<br /> <br /> Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the<br /> successful getname() call, so that when the request is torn down, the<br /> filename will be cleaned up, along with other resources needing cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: ets: Remove drr class from the active list if it changes to strict<br /> <br /> Whenever a user issues an ets qdisc change command, transforming a<br /> drr class into a strict one, the ets code isn&amp;#39;t checking whether that<br /> class was in the active list and removing it. This means that, if a<br /> user changes a strict class (which was in the active list) back to a drr<br /> one, that class will be added twice to the active list [1].<br /> <br /> Doing so with the following commands:<br /> <br /> tc qdisc add dev lo root handle 1: ets bands 2 strict 1<br /> tc qdisc add dev lo parent 1:2 handle 20: \<br /> tbf rate 8bit burst 100b latency 1s<br /> tc filter add dev lo parent 1: basic classid 1:2<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 2<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 1<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> <br /> Will trigger the following splat with list debug turned on:<br /> <br /> [ 59.279014][ T365] ------------[ cut here ]------------<br /> [ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.<br /> [ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220<br /> [ 59.280860][ T365] Modules linked in:<br /> [ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)<br /> [ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220<br /> [ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44<br /> ...<br /> [ 59.288812][ T365] Call Trace:<br /> [ 59.289056][ T365] <br /> [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80<br /> [ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0<br /> [ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10<br /> [ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240<br /> [ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10<br /> [ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.292313][ T365] ? trace_contention_end+0xc8/0x110<br /> [ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0<br /> <br /> Fix this by always checking and removing an ets class from the active list<br /> when changing it to strict.<br /> <br /> [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: fw_tracer, Validate format string parameters<br /> <br /> Add validation for format string parameters in the firmware tracer to<br /> prevent potential security vulnerabilities and crashes from malformed<br /> format strings received from firmware.<br /> <br /> The firmware tracer receives format strings from the device firmware and<br /> uses them to format trace messages. Without proper validation, bad<br /> firmware could provide format strings with invalid format specifiers<br /> (e.g., %s, %p, %n) that could lead to crashes, or other undefined<br /> behavior.<br /> <br /> Add mlx5_tracer_validate_params() to validate that all format specifiers<br /> in trace strings are limited to safe integer/hex formats (%x, %d, %i,<br /> %u, %llx, %lx, etc.). Reject strings containing other format types that<br /> could be used to access arbitrary memory or cause crashes.<br /> Invalid format strings are added to the trace output for visibility with<br /> "BAD_FORMAT: " prefix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats<br /> <br /> Cited commit added a dedicated mutex (instead of RTNL) to protect the<br /> multicast route list, so that it will not change while the driver<br /> periodically traverses it in order to update the kernel about multicast<br /> route stats that were queried from the device.<br /> <br /> One instance of list entry deletion (during route replace) was missed<br /> and it can result in a use-after-free [1].<br /> <br /> Fix by acquiring the mutex before deleting the entry from the list and<br /> releasing it afterwards.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]<br /> Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043<br /> <br /> CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)<br /> Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017<br /> Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> print_report+0x174/0x4f5<br /> kasan_report+0xdf/0x110<br /> mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 29933:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]<br /> mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 29933:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3b/0x70<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x14e/0x700<br /> mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]<br /> mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30