Vulnerabilities

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 /> media: iris: Add sanity check for stop streaming<br /> <br /> Add sanity check in iris_vb2_stop_streaming. If inst-&gt;state is<br /> already IRIS_INST_ERROR, we should skip the stream_off operation<br /> because it would still send packets to the firmware.<br /> <br /> In iris_kill_session, inst-&gt;state is set to IRIS_INST_ERROR and<br /> session_close is executed, which will kfree(inst_hfi_gen2-&gt;packet).<br /> If stop_streaming is called afterward, it will cause a crash.<br /> <br /> [bod: remove qcom from patch title]

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 /> 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 /> drm/xe: Limit num_syncs to prevent oversized allocations<br /> <br /> The exec and vm_bind ioctl allow userspace to specify an arbitrary<br /> num_syncs value. Without bounds checking, a very large num_syncs<br /> can force an excessively large allocation, leading to kernel warnings<br /> from the page allocator as below.<br /> <br /> Introduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request<br /> exceeding this limit.<br /> <br /> "<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124<br /> ...<br /> Call Trace:<br /> <br /> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416<br /> ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317<br /> __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348<br /> __do_kmalloc_node mm/slub.c:4364 [inline]<br /> __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388<br /> kmalloc_noprof include/linux/slab.h:909 [inline]<br /> kmalloc_array_noprof include/linux/slab.h:948 [inline]<br /> xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158<br /> drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797<br /> drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894<br /> xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:598 [inline]<br /> __se_sys_ioctl fs/ioctl.c:584 [inline]<br /> __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...<br /> "<br /> <br /> v2: Add "Reported-by" and Cc stable kernels.<br /> v3: Change XE_MAX_SYNCS from 64 to 1024. (Matt &amp; Ashutosh)<br /> v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt)<br /> v5: Do the check at the top of the exec func. (Matt)<br /> <br /> (cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix io-uring list corruption for terminated non-committed requests<br /> <br /> When a request is terminated before it has been committed, the request<br /> is not removed from the queue&amp;#39;s list. This leaves a dangling list entry<br /> that leads to list corruption and use-after-free issues.<br /> <br /> Remove the request from the queue&amp;#39;s list for terminated non-committed<br /> requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix buffer validation by including null terminator size in EA length<br /> <br /> The smb2_set_ea function, which handles Extended Attributes (EA),<br /> was performing buffer validation checks that incorrectly omitted the size<br /> of the null terminating character (+1 byte) for EA Name.<br /> This patch fixes the issue by explicitly adding &amp;#39;+ 1&amp;#39; to EaNameLength where<br /> the null terminator is expected to be present in the buffer, ensuring<br /> the validation accurately reflects the total required buffer size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix race between wbt_enable_default and IO submission<br /> <br /> When wbt_enable_default() is moved out of queue freezing in elevator_change(),<br /> it can cause the wbt inflight counter to become negative (-1), leading to hung<br /> tasks in the writeback path. Tasks get stuck in wbt_wait() because the counter<br /> is in an inconsistent state.<br /> <br /> The issue occurs because wbt_enable_default() could race with IO submission,<br /> allowing the counter to be decremented before proper initialization. This manifests<br /> as:<br /> <br /> rq_wait[0]:<br /> inflight: -1<br /> has_waiters: True<br /> <br /> rwb_enabled() checks the state, which can be updated exactly between wbt_wait()<br /> (rq_qos_throttle()) and wbt_track()(rq_qos_track()), then the inflight counter<br /> will become negative.<br /> <br /> And results in hung task warnings like:<br /> task:kworker/u24:39 state:D stack:0 pid:14767<br /> Call Trace:<br /> rq_qos_wait+0xb4/0x150<br /> wbt_wait+0xa9/0x100<br /> __rq_qos_throttle+0x24/0x40<br /> blk_mq_submit_bio+0x672/0x7b0<br /> ...<br /> <br /> Fix this by:<br /> <br /> 1. Splitting wbt_enable_default() into:<br /> - __wbt_enable_default(): Returns true if wbt_init() should be called<br /> - wbt_enable_default(): Wrapper for existing callers (no init)<br /> - wbt_init_enable_default(): New function that checks and inits WBT<br /> <br /> 2. Using wbt_init_enable_default() in blk_register_queue() to ensure<br /> proper initialization during queue registration<br /> <br /> 3. Move wbt_init() out of wbt_enable_default() which is only for enabling<br /> disabled wbt from bfq and iocost, and wbt_init() isn&amp;#39;t needed. Then the<br /> original lock warning can be avoided.<br /> <br /> 4. Removing the ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT flag and its handling<br /> code since it&amp;#39;s no longer needed<br /> <br /> This ensures WBT is properly initialized before any IO can be submitted,<br /> preventing the counter from going negative.

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