Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> be2net: pass wrb_params in case of OS2BMC<br /> <br /> be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL<br /> at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL<br /> pointer when processing a workaround for specific packet, as commit<br /> bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6<br /> packet") states.<br /> <br /> The correct way would be to pass the wrb_params from be_xmit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfat: fix missing sb_min_blocksize() return value checks<br /> <br /> When emulating an nvme device on qemu with both logical_block_size and<br /> physical_block_size set to 8 KiB, but without format, a kernel panic<br /> was triggered during the early boot stage while attempting to mount a<br /> vfat filesystem.<br /> <br /> [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize<br /> [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize<br /> [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize<br /> [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192<br /> [95553.697117] ------------[ cut here ]------------<br /> [95553.697567] kernel BUG at fs/buffer.c:1582!<br /> [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary)<br /> [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0<br /> [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f<br /> [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246<br /> [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001<br /> [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000<br /> [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000<br /> [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000<br /> [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0<br /> [95553.708439] PKRU: 55555554<br /> [95553.708734] Call Trace:<br /> [95553.709015] <br /> [95553.709266] __getblk_slow+0xd2/0x230<br /> [95553.709641] ? find_get_block_common+0x8b/0x530<br /> [95553.710084] bdev_getblk+0x77/0xa0<br /> [95553.710449] __bread_gfp+0x22/0x140<br /> [95553.710810] fat_fill_super+0x23a/0xfc0<br /> [95553.711216] ? __pfx_setup+0x10/0x10<br /> [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10<br /> [95553.712014] vfat_fill_super+0x15/0x30<br /> [95553.712401] get_tree_bdev_flags+0x141/0x1e0<br /> [95553.712817] get_tree_bdev+0x10/0x20<br /> [95553.713177] vfat_get_tree+0x15/0x20<br /> [95553.713550] vfs_get_tree+0x2a/0x100<br /> [95553.713910] vfs_cmd_create+0x62/0xf0<br /> [95553.714273] __do_sys_fsconfig+0x4e7/0x660<br /> [95553.714669] __x64_sys_fsconfig+0x20/0x40<br /> [95553.715062] x64_sys_call+0x21ee/0x26a0<br /> [95553.715453] do_syscall_64+0x80/0x670<br /> [95553.715816] ? __fs_parse+0x65/0x1e0<br /> [95553.716172] ? fat_parse_param+0x103/0x4b0<br /> [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0<br /> [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660<br /> [95553.717548] ? __x64_sys_fsconfig+0x20/0x40<br /> [95553.717957] ? x64_sys_call+0x21ee/0x26a0<br /> [95553.718360] ? do_syscall_64+0xb8/0x670<br /> [95553.718734] ? __x64_sys_fsconfig+0x20/0x40<br /> [95553.719141] ? x64_sys_call+0x21ee/0x26a0<br /> [95553.719545] ? do_syscall_64+0xb8/0x670<br /> [95553.719922] ? x64_sys_call+0x1405/0x26a0<br /> [95553.720317] ? do_syscall_64+0xb8/0x670<br /> [95553.720702] ? __x64_sys_close+0x3e/0x90<br /> [95553.721080] ? x64_sys_call+0x1b5e/0x26a0<br /> [95553.721478] ? do_syscall_64+0xb8/0x670<br /> [95553.721841] ? irqentry_exit+0x43/0x50<br /> [95553.722211] ? exc_page_fault+0x90/0x1b0<br /> [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [95553.723166] RIP: 0033:0x72ee774f3afe<br /> [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48<br /> [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af<br /> [95553.725892] RAX: ffffffffffffffda RBX: <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Check the untrusted offset in FF-A memory share<br /> <br /> Verify the offset to prevent OOB access in the hypervisor<br /> FF-A buffer in case an untrusted large enough value<br /> [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX]<br /> is set from the host kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: remove never-working support for setting nsh fields<br /> <br /> The validation of the set(nsh(...)) action is completely wrong.<br /> It runs through the nsh_key_put_from_nlattr() function that is the<br /> same function that validates NSH keys for the flow match and the<br /> push_nsh() action. However, the set(nsh(...)) has a very different<br /> memory layout. Nested attributes in there are doubled in size in<br /> case of the masked set(). That makes proper validation impossible.<br /> <br /> There is also confusion in the code between the &amp;#39;masked&amp;#39; flag, that<br /> says that the nested attributes are doubled in size containing both<br /> the value and the mask, and the &amp;#39;is_mask&amp;#39; that says that the value<br /> we&amp;#39;re parsing is the mask. This is causing kernel crash on trying to<br /> write into mask part of the match with SW_FLOW_KEY_PUT() during<br /> validation, while validate_nsh() doesn&amp;#39;t allocate any memory for it:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary)<br /> RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch]<br /> Call Trace:<br /> <br /> validate_nsh+0x60/0x90 [openvswitch]<br /> validate_set.constprop.0+0x270/0x3c0 [openvswitch]<br /> __ovs_nla_copy_actions+0x477/0x860 [openvswitch]<br /> ovs_nla_copy_actions+0x8d/0x100 [openvswitch]<br /> ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch]<br /> genl_family_rcv_msg_doit+0xdb/0x130<br /> genl_family_rcv_msg+0x14b/0x220<br /> genl_rcv_msg+0x47/0xa0<br /> netlink_rcv_skb+0x53/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x280/0x3b0<br /> netlink_sendmsg+0x1f7/0x430<br /> ____sys_sendmsg+0x36b/0x3a0<br /> ___sys_sendmsg+0x87/0xd0<br /> __sys_sendmsg+0x6d/0xd0<br /> do_syscall_64+0x7b/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The third issue with this process is that while trying to convert<br /> the non-masked set into masked one, validate_set() copies and doubles<br /> the size of the OVS_KEY_ATTR_NSH as if it didn&amp;#39;t have any nested<br /> attributes. It should be copying each nested attribute and doubling<br /> them in size independently. And the process must be properly reversed<br /> during the conversion back from masked to a non-masked variant during<br /> the flow dump.<br /> <br /> In the end, the only two outcomes of trying to use this action are<br /> either validation failure or a kernel crash. And if somehow someone<br /> manages to install a flow with such an action, it will most definitely<br /> not do what it is supposed to, since all the keys and the masks are<br /> mixed up.<br /> <br /> Fixing all the issues is a complex task as it requires re-writing<br /> most of the validation code.<br /> <br /> Given that and the fact that this functionality never worked since<br /> introduction, let&amp;#39;s just remove it altogether. It&amp;#39;s better to<br /> re-introduce it later with a proper implementation instead of trying<br /> to fix it in stable releases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()<br /> <br /> The ethtool tsconfig Netlink path can trigger a null pointer<br /> dereference. A call chain such as:<br /> <br /> tsconfig_prepare_data() -&gt;<br /> dev_get_hwtstamp_phylib() -&gt;<br /> vlan_hwtstamp_get() -&gt;<br /> generic_hwtstamp_get_lower() -&gt;<br /> generic_hwtstamp_ioctl_lower()<br /> <br /> results in generic_hwtstamp_ioctl_lower() being called with<br /> kernel_cfg-&gt;ifr as NULL.<br /> <br /> The generic_hwtstamp_ioctl_lower() function does not expect<br /> a NULL ifr and dereferences it, leading to a system crash.<br /> <br /> Fix this by adding a NULL check for kernel_cfg-&gt;ifr in<br /> generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added<br /> <br /> In commit b441cf3f8c4b ("xfrm: delete x-&gt;tunnel as we delete x"), I<br /> missed the case where state creation fails between full<br /> initialization (-&gt;init_state has been called) and being inserted on<br /> the lists.<br /> <br /> In this situation, -&gt;init_state has been called, so for IPcomp<br /> tunnels, the fallback tunnel has been created and added onto the<br /> lists, but the user state never gets added, because we fail before<br /> that. The user state doesn&amp;#39;t go through __xfrm_state_delete, so we<br /> don&amp;#39;t call xfrm_state_delete_tunnel for those states, and we end up<br /> leaking the FB tunnel.<br /> <br /> There are several codepaths affected by this: the add/update paths, in<br /> both net/key and xfrm, and the migrate code (xfrm_migrate,<br /> xfrm_state_migrate). A "proper" rollback of the init_state work would<br /> probably be doable in the add/update code, but for migrate it gets<br /> more complicated as multiple states may be involved.<br /> <br /> At some point, the new (not-inserted) state will be destroyed, so call<br /> xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states<br /> will have their fallback tunnel cleaned up during __xfrm_state_delete,<br /> which solves the issue that b441cf3f8c4b (and other patches before it)<br /> aimed at. All states (including FB tunnels) will be removed from the<br /> lists once xfrm_state_fini has called flush_work(&amp;xfrm_state_gc_work).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix a race in mptcp_pm_del_add_timer()<br /> <br /> mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &amp;entry-&gt;add_timer)<br /> while another might have free entry already, as reported by syzbot.<br /> <br /> Add RCU protection to fix this issue.<br /> <br /> Also change confusing add_timer variable with stop_timer boolean.<br /> <br /> syzbot report:<br /> <br /> BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616<br /> Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44<br /> <br /> CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)}<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025<br /> Workqueue: events mptcp_worker<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616<br /> sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631<br /> mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362<br /> mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174<br /> tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361<br /> tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441<br /> tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931<br /> tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374<br /> ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239<br /> NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318<br /> NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318<br /> __netif_receive_skb_one_core net/core/dev.c:6079 [inline]<br /> __netif_receive_skb+0x143/0x380 net/core/dev.c:6192<br /> process_backlog+0x31e/0x900 net/core/dev.c:6544<br /> __napi_poll+0xb6/0x540 net/core/dev.c:7594<br /> napi_poll net/core/dev.c:7657 [inline]<br /> net_rx_action+0x5f7/0xda0 net/core/dev.c:7784<br /> handle_softirqs+0x22f/0x710 kernel/softirq.c:622<br /> __do_softirq kernel/softirq.c:656 [inline]<br /> __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302<br /> mptcp_pm_send_ack net/mptcp/pm.c:210 [inline]<br /> mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1<br /> mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002<br /> mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762<br /> process_one_work kernel/workqueue.c:3263 [inline]<br /> process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> Allocated by task 44:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> poison_kmalloc_redzone mm/kasan/common.c:400 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417<br /> kasan_kmalloc include/linux/kasan.h:262 [inline]<br /> __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748<br /> kmalloc_noprof include/linux/slab.h:957 [inline]<br /> mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385<br /> mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355<br /> mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline]<br /> __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529<br /> mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008<br /> mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762<br /> process_one_work kernel/workqueue.c:3263 [inline]<br /> process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> Freed by task 6630:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587<br /> kasan_save_free_info mm/kasan/kasan.h:406 [inline]<br /> poison_slab_object m<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix race condition in mptcp_schedule_work()<br /> <br /> syzbot reported use-after-free in mptcp_schedule_work() [1]<br /> <br /> Issue here is that mptcp_schedule_work() schedules a work,<br /> then gets a refcount on sk-&gt;sk_refcnt if the work was scheduled.<br /> This refcount will be released by mptcp_worker().<br /> <br /> [A] if (schedule_work(...)) {<br /> [B] sock_hold(sk);<br /> return true;<br /> }<br /> <br /> Problem is that mptcp_worker() can run immediately and complete before [B]<br /> <br /> We need instead :<br /> <br /> sock_hold(sk);<br /> if (schedule_work(...))<br /> return true;<br /> sock_put(sk);<br /> <br /> [1]<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25<br /> Call Trace:<br /> <br /> __refcount_add include/linux/refcount.h:-1 [inline]<br /> __refcount_inc include/linux/refcount.h:366 [inline]<br /> refcount_inc include/linux/refcount.h:383 [inline]<br /> sock_hold include/net/sock.h:816 [inline]<br /> mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943<br /> mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316<br /> call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747<br /> expire_timers kernel/time/timer.c:1798 [inline]<br /> __run_timers kernel/time/timer.c:2372 [inline]<br /> __run_timer_base+0x648/0x970 kernel/time/timer.c:2384<br /> run_timer_base kernel/time/timer.c:2393 [inline]<br /> run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403<br /> handle_softirqs+0x22f/0x710 kernel/softirq.c:622<br /> __do_softirq kernel/softirq.c:656 [inline]<br /> run_ktimerd+0xcf/0x190 kernel/softirq.c:1138<br /> smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Do not sleep in atomic context<br /> <br /> sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may<br /> sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead<br /> of disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix scx_enable() crash on helper kthread creation failure<br /> <br /> A crash was observed when the sched_ext selftests runner was<br /> terminated with Ctrl+\ while test 15 was running:<br /> <br /> NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0<br /> LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0<br /> Call Trace:<br /> scx_enable.constprop.0+0x32c/0x12b0 (unreliable)<br /> bpf_struct_ops_link_create+0x18c/0x22c<br /> __sys_bpf+0x23f8/0x3044<br /> sys_bpf+0x2c/0x6c<br /> system_call_exception+0x124/0x320<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> kthread_run_worker() returns an ERR_PTR() on failure rather than NULL,<br /> but the current code in scx_alloc_and_add_sched() only checks for a NULL<br /> helper. Incase of failure on SIGQUIT, the error is not handled in<br /> scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an<br /> error pointer.<br /> <br /> Error handling is fixed in scx_alloc_and_add_sched() to propagate<br /> PTR_ERR() into ret, so that scx_enable() jumps to the existing error<br /> path, avoiding random dereference on failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: rate: Unset parent pointer in devl_rate_nodes_destroy<br /> <br /> The function devl_rate_nodes_destroy is documented to "Unset parent for<br /> all rate objects". However, it was only calling the driver-specific<br /> `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing<br /> the parent&amp;#39;s refcount, without actually setting the<br /> `devlink_rate-&gt;parent` pointer to NULL.<br /> <br /> This leaves a dangling pointer in the `devlink_rate` struct, which cause<br /> refcount error in netdevsim[1] and mlx5[2]. In addition, this is<br /> inconsistent with the behavior of `devlink_nl_rate_parent_node_set`,<br /> where the parent pointer is correctly cleared.<br /> <br /> This patch fixes the issue by explicitly setting `devlink_rate-&gt;parent`<br /> to NULL after notifying the driver, thus fulfilling the function&amp;#39;s<br /> documented behavior for all rate objects.<br /> <br /> [1]<br /> repro steps:<br /> echo 1 &gt; /sys/bus/netdevsim/new_device<br /> devlink dev eswitch set netdevsim/netdevsim1 mode switchdev<br /> echo 1 &gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs<br /> devlink port function rate add netdevsim/netdevsim1/test_node<br /> devlink port function rate set netdevsim/netdevsim1/128 parent test_node<br /> echo 1 &gt; /sys/bus/netdevsim/del_device<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> __nsim_dev_port_del+0x6c/0x70 [netdevsim]<br /> nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]<br /> nsim_drv_remove+0x2b/0xb0 [netdevsim]<br /> device_release_driver_internal+0x194/0x1f0<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x159/0x3c0<br /> device_unregister+0x1a/0x60<br /> del_device_store+0x111/0x170 [netdevsim]<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x55/0x10f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> devlink dev eswitch set pci/0000:08:00.0 mode switchdev<br /> devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000<br /> devlink port function rate add pci/0000:08:00.0/group1<br /> devlink port function rate set pci/0000:08:00.0/32768 parent group1<br /> modprobe -r mlx5_ib mlx5_fwctl mlx5_core<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]<br /> mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]<br /> mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]<br /> mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]<br /> notifier_call_chain+0x33/0xa0<br /> blocking_notifier_call_chain+0x3b/0x50<br /> mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]<br /> mlx5_eswitch_disable+0x63/0x90 [mlx5_core]<br /> mlx5_unload+0x1d/0x170 [mlx5_core]<br /> mlx5_uninit_one+0xa2/0x130 [mlx5_core]<br /> remove_one+0x78/0xd0 [mlx5_core]<br /> pci_device_remove+0x39/0xa0<br /> device_release_driver_internal+0x194/0x1f0<br /> unbind_store+0x99/0xa0<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x53/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix pgtable prealloc error path<br /> <br /> The following splat was reported:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000<br /> [0000000000000010] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT)<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : build_detached_freelist+0x28/0x224<br /> lr : kmem_cache_free_bulk.part.0+0x38/0x244<br /> sp : ffff000a508c7a20<br /> x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350<br /> x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000<br /> x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000<br /> x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8<br /> x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640<br /> x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30<br /> x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940<br /> x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000<br /> x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8<br /> x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00<br /> Call trace:<br /> build_detached_freelist+0x28/0x224 (P)<br /> kmem_cache_free_bulk.part.0+0x38/0x244<br /> kmem_cache_free_bulk+0x10/0x1c<br /> msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0<br /> msm_vma_job_free+0x30/0x240<br /> msm_ioctl_vm_bind+0x1d0/0x9a0<br /> drm_ioctl_kernel+0x84/0x104<br /> drm_ioctl+0x358/0x4d4<br /> __arm64_sys_ioctl+0x8c/0xe0<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0x3c/0xe0<br /> do_el0_svc+0x18/0x20<br /> el0_svc+0x30/0x100<br /> el0t_64_sync_handler+0x104/0x130<br /> el0t_64_sync+0x170/0x174<br /> Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Since msm_vma_job_free() is called directly from the ioctl, this looks<br /> like an error path cleanup issue. Which I think results from<br /> prealloc_cleanup() called without a preceding successful<br /> prealloc_allocate() call. So handle that case better.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/678677/