Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kasan: avoid sleepable page allocation from atomic context<br /> <br /> apply_to_pte_range() enters the lazy MMU mode and then invokes<br /> kasan_populate_vmalloc_pte() callback on each page table walk iteration. <br /> However, the callback can go into sleep when trying to allocate a single<br /> page, e.g. if an architecutre disables preemption on lazy MMU mode enter.<br /> <br /> On s390 if make arch_enter_lazy_mmu_mode() -&gt; preempt_enable() and<br /> arch_leave_lazy_mmu_mode() -&gt; preempt_disable(), such crash occurs:<br /> <br /> [ 0.663336] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:321<br /> [ 0.663348] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd<br /> [ 0.663358] preempt_count: 1, expected: 0<br /> [ 0.663366] RCU nest depth: 0, expected: 0<br /> [ 0.663375] no locks held by kthreadd/2.<br /> [ 0.663383] Preemption disabled at:<br /> [ 0.663386] [] apply_to_pte_range+0xfa/0x4a0<br /> [ 0.663405] CPU: 0 UID: 0 PID: 2 Comm: kthreadd Not tainted 6.15.0-rc5-gcc-kasan-00043-gd76bb1ebb558-dirty #162 PREEMPT<br /> [ 0.663408] Hardware name: IBM 3931 A01 701 (KVM/Linux)<br /> [ 0.663409] Call Trace:<br /> [ 0.663410] [] dump_stack_lvl+0xe8/0x140<br /> [ 0.663413] [] __might_resched+0x66e/0x700<br /> [ 0.663415] [] __alloc_frozen_pages_noprof+0x370/0x4b0<br /> [ 0.663419] [] alloc_pages_mpol+0x1a0/0x4a0<br /> [ 0.663421] [] alloc_frozen_pages_noprof+0x88/0xc0<br /> [ 0.663424] [] alloc_pages_noprof+0x22/0x120<br /> [ 0.663427] [] get_free_pages_noprof+0x2c/0xc0<br /> [ 0.663429] [] kasan_populate_vmalloc_pte+0x50/0x120<br /> [ 0.663433] [] apply_to_pte_range+0x118/0x4a0<br /> [ 0.663435] [] apply_to_pmd_range+0x194/0x3e0<br /> [ 0.663437] [] __apply_to_page_range+0x2fe/0x7a0<br /> [ 0.663440] [] apply_to_page_range+0x28/0x40<br /> [ 0.663442] [] kasan_populate_vmalloc+0x82/0xa0<br /> [ 0.663445] [] alloc_vmap_area+0x34c/0xc10<br /> [ 0.663448] [] __get_vm_area_node+0x186/0x2a0<br /> [ 0.663451] [] __vmalloc_node_range_noprof+0x116/0x310<br /> [ 0.663454] [] __vmalloc_node_noprof+0xd0/0x110<br /> [ 0.663457] [] alloc_thread_stack_node+0xf8/0x330<br /> [ 0.663460] [] dup_task_struct+0x66/0x4d0<br /> [ 0.663463] [] copy_process+0x280/0x4b90<br /> [ 0.663465] [] kernel_clone+0xd0/0x4b0<br /> [ 0.663467] [] kernel_thread+0xbe/0xe0<br /> [ 0.663469] [] kthreadd+0x50e/0x7f0<br /> [ 0.663472] [] __ret_from_fork+0x8a/0xf0<br /> [ 0.663475] [] ret_from_fork+0xa/0x38<br /> <br /> Instead of allocating single pages per-PTE, bulk-allocate the shadow<br /> memory prior to applying kasan_populate_vmalloc_pte() callback on a page<br /> range.

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 /> dmaengine: idxd: fix memory leak in error handling path of idxd_alloc<br /> <br /> Memory allocated for idxd is not freed if an error occurs during<br /> idxd_alloc(). To fix it, free the allocated memory in the reverse order<br /> of allocation before exiting the function in case of an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: bpf: abort dispatch if device destroyed<br /> <br /> The current HID bpf implementation assumes no output report/request will<br /> go through it after hid_bpf_destroy_device() has been called. This leads<br /> to a bug that unplugging certain types of HID devices causes a cleaned-<br /> up SRCU to be accessed. The bug was previously a hidden failure until a<br /> recent x86 percpu change [1] made it access not-present pages.<br /> <br /> The bug will be triggered if the conditions below are met:<br /> <br /> A) a device under the driver has some LEDs on<br /> B) hid_ll_driver-&gt;request() is uninplemented (e.g., logitech-djreceiver)<br /> <br /> If condition A is met, hidinput_led_worker() is always scheduled *after*<br /> hid_bpf_destroy_device().<br /> <br /> hid_destroy_device<br /> ` hid_bpf_destroy_device<br /> ` cleanup_srcu_struct(&amp;hdev-&gt;bpf.srcu)<br /> ` hid_remove_device<br /> ` ...<br /> ` led_classdev_unregister<br /> ` led_trigger_set(led_cdev, NULL)<br /> ` led_set_brightness(led_cdev, LED_OFF)<br /> ` ...<br /> ` input_inject_event<br /> ` input_event_dispose<br /> ` hidinput_input_event<br /> ` schedule_work(&amp;hid-&gt;led_work) [hidinput_led_worker]<br /> <br /> This is fine when condition B is not met, where hidinput_led_worker()<br /> calls hid_ll_driver-&gt;request(). This is the case for most HID drivers,<br /> which implement it or use the generic one from usbhid. The driver itself<br /> or an underlying driver will then abort processing the request.<br /> <br /> Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads<br /> to the bug.<br /> <br /> hidinput_led_worker<br /> ` hid_hw_output_report<br /> ` dispatch_hid_bpf_output_report<br /> ` srcu_read_lock(&amp;hdev-&gt;bpf.srcu)<br /> ` srcu_read_unlock(&amp;hdev-&gt;bpf.srcu, idx)<br /> <br /> The bug has existed since the introduction [2] of<br /> dispatch_hid_bpf_output_report(). However, the same bug also exists in<br /> dispatch_hid_bpf_raw_requests(), and I&amp;#39;ve reproduced (no visible effect<br /> because of the lack of [1], but confirmed bpf.destroyed == 1) the bug<br /> against the commit (i.e., the Fixes:) introducing the function. This is<br /> because hidinput_led_worker() falls back to hid_hw_raw_request() when<br /> hid_ll_driver-&gt;output_report() is uninplemented (e.g., logitech-<br /> djreceiver).<br /> <br /> hidinput_led_worker<br /> ` hid_hw_output_report: -ENOSYS<br /> ` hid_hw_raw_request<br /> ` dispatch_hid_bpf_raw_requests<br /> ` srcu_read_lock(&amp;hdev-&gt;bpf.srcu)<br /> ` srcu_read_unlock(&amp;hdev-&gt;bpf.srcu, idx)<br /> <br /> Fix the issue by returning early in the two mentioned functions if<br /> hid_bpf has been marked as destroyed. Though<br /> dispatch_hid_bpf_device_event() handles input events, and there is no<br /> evidence that it may be called after the destruction, the same check, as<br /> a safety net, is also added to it to maintain the consistency among all<br /> dispatch functions.<br /> <br /> The impact of the bug on other architectures is unclear. Even if it acts<br /> as a hidden failure, this is still dangerous because it corrupts<br /> whatever is on the address calculated by SRCU. Thus, CC&amp;#39;ing the stable<br /> list.<br /> <br /> [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets")<br /> [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for<br /> hid_hw_output_report")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/eventpoll: fix endless busy loop after timeout has expired<br /> <br /> After commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it&amp;#39;s in<br /> the future"), the following program would immediately enter a busy<br /> loop in the kernel:<br /> <br /> ```<br /> int main() {<br /> int e = epoll_create1(0);<br /> struct epoll_event event = {.events = EPOLLIN};<br /> epoll_ctl(e, EPOLL_CTL_ADD, 0, &amp;event);<br /> const struct timespec timeout = {.tv_nsec = 1};<br /> epoll_pwait2(e, &amp;event, 1, &amp;timeout, 0);<br /> }<br /> ```<br /> <br /> This happens because the given (non-zero) timeout of 1 nanosecond<br /> usually expires before ep_poll() is entered and then<br /> ep_schedule_timeout() returns false, but `timed_out` is never set<br /> because the code line that sets it is skipped. This quickly turns<br /> into a soft lockup, RCU stalls and deadlocks, inflicting severe<br /> headaches to the whole system.<br /> <br /> When the timeout has expired, we don&amp;#39;t need to schedule a hrtimer, but<br /> we should set the `timed_out` variable. Therefore, I suggest moving<br /> the ep_schedule_timeout() check into the `timed_out` expression<br /> instead of skipping it.<br /> <br /> brauner: Note that there was an earlier fix by Joe Damato in response to<br /> my bug report in [1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tls: fix kernel panic when alloc_page failed<br /> <br /> We cannot set frag_list to NULL pointer when alloc_page failed.<br /> It will be used in tls_strp_check_queue_ok when the next time<br /> tls_strp_read_sock is called.<br /> <br /> This is because we don&amp;#39;t reset full_len in tls_strp_flush_anchor_copy()<br /> so the recv path will try to continue handling the partial record<br /> on the next call but we dettached the rcvq from the frag list.<br /> Alternative fix would be to reset full_len.<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> at virtual address 0000000000000028<br /> Call trace:<br /> tls_strp_check_rcv+0x128/0x27c<br /> tls_strp_data_ready+0x34/0x44<br /> tls_data_ready+0x3c/0x1f0<br /> tcp_data_ready+0x9c/0xe4<br /> tcp_data_queue+0xf6c/0x12d0<br /> tcp_rcv_established+0x52c/0x798

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices<br /> <br /> The driver only offloads neighbors that are constructed on top of net<br /> devices registered by it or their uppers (which are all Ethernet). The<br /> device supports GRE encapsulation and decapsulation of forwarded<br /> traffic, but the driver will not offload dummy neighbors constructed on<br /> top of GRE net devices as they are not uppers of its net devices:<br /> <br /> # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1<br /> # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1<br /> $ ip neigh show dev gre1 nud noarp<br /> 0.0.0.0 lladdr 0.0.0.0 NOARP<br /> <br /> (Note that the neighbor is not marked with &amp;#39;offload&amp;#39;)<br /> <br /> When the driver is reloaded and the existing configuration is replayed,<br /> the driver does not perform the same check regarding existing neighbors<br /> and offloads the previously added one:<br /> <br /> # devlink dev reload pci/0000:01:00.0<br /> $ ip neigh show dev gre1 nud noarp<br /> 0.0.0.0 lladdr 0.0.0.0 offload NOARP<br /> <br /> If the neighbor is later deleted, the driver will ignore the<br /> notification (given the GRE net device is not its upper) and will<br /> therefore keep referencing freed memory, resulting in a use-after-free<br /> [1] when the net device is deleted:<br /> <br /> # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1<br /> # ip link del dev gre1<br /> <br /> Fix by skipping neighbor replay if the net device for which the replay<br /> is performed is not our upper.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200<br /> Read of size 8 at addr ffff888155b0e420 by task ip/2282<br /> [...]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_address_description.constprop.0+0x6f/0x350<br /> print_report+0x108/0x205<br /> kasan_report+0xdf/0x110<br /> mlxsw_sp_neigh_entry_update+0x1ea/0x200<br /> mlxsw_sp_router_rif_gone_sync+0x2a8/0x440<br /> mlxsw_sp_rif_destroy+0x1e9/0x750<br /> mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0<br /> mlxsw_sp_router_netdevice_event+0x3ac/0x15e0<br /> notifier_call_chain+0xca/0x150<br /> call_netdevice_notifiers_info+0x7f/0x100<br /> unregister_netdevice_many_notify+0xc8c/0x1d90<br /> rtnl_dellink+0x34e/0xa50<br /> rtnetlink_rcv_msg+0x6fb/0xb70<br /> netlink_rcv_skb+0x131/0x360<br /> netlink_unicast+0x426/0x710<br /> netlink_sendmsg+0x75a/0xc20<br /> __sock_sendmsg+0xc1/0x150<br /> ____sys_sendmsg+0x5aa/0x7b0<br /> ___sys_sendmsg+0xfc/0x180<br /> __sys_sendmsg+0x121/0x1b0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Disable MACsec offload for uplink representor profile<br /> <br /> MACsec offload is not supported in switchdev mode for uplink<br /> representors. When switching to the uplink representor profile, the<br /> MACsec offload feature must be cleared from the netdevice&amp;#39;s features.<br /> <br /> If left enabled, attempts to add offloads result in a null pointer<br /> dereference, as the uplink representor does not support MACsec offload<br /> even though the feature bit remains set.<br /> <br /> Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().<br /> <br /> Kernel log:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1<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:__mutex_lock+0x128/0x1dd0<br /> Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff<br /> RSP: 0018:ffff888147a4f160 EFLAGS: 00010206<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001<br /> RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078<br /> RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000<br /> FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? die_addr+0x3d/0xa0<br /> ? exc_general_protection+0x144/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? __mutex_lock+0x128/0x1dd0<br /> ? lockdep_set_lock_cmp_fn+0x190/0x190<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? mutex_lock_io_nested+0x1ae0/0x1ae0<br /> ? lock_acquire+0x1c2/0x530<br /> ? macsec_upd_offload+0x145/0x380<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? kasan_save_stack+0x30/0x40<br /> ? kasan_save_stack+0x20/0x40<br /> ? kasan_save_track+0x10/0x30<br /> ? __kasan_kmalloc+0x77/0x90<br /> ? __kmalloc_noprof+0x249/0x6b0<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240<br /> ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]<br /> ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]<br /> macsec_update_offload+0x26c/0x820<br /> ? macsec_set_mac_address+0x4b0/0x4b0<br /> ? lockdep_hardirqs_on_prepare+0x284/0x400<br /> ? _raw_spin_unlock_irqrestore+0x47/0x50<br /> macsec_upd_offload+0x2c8/0x380<br /> ? macsec_update_offload+0x820/0x820<br /> ? __nla_parse+0x22/0x30<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240<br /> genl_family_rcv_msg_doit+0x1cc/0x2a0<br /> ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240<br /> ? cap_capable+0xd4/0x330<br /> genl_rcv_msg+0x3ea/0x670<br /> ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0<br /> ? lockdep_set_lock_cmp_fn+0x190/0x190<br /> ? macsec_update_offload+0x820/0x820<br /> netlink_rcv_skb+0x12b/0x390<br /> ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0<br /> ? netlink_ack+0xd80/0xd80<br /> ? rwsem_down_read_slowpath+0xf90/0xf90<br /> ? netlink_deliver_tap+0xcd/0xac0<br /> ? netlink_deliver_tap+0x155/0xac0<br /> ? _copy_from_iter+0x1bb/0x12c0<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x440/0x700<br /> ? netlink_attachskb+0x760/0x760<br /> ? lock_acquire+0x1c2/0x530<br /> ? __might_fault+0xbb/0x170<br /> netlink_sendmsg+0x749/0xc10<br /> ? netlink_unicast+0x700/0x700<br /> ? __might_fault+0xbb/0x170<br /> ? netlink_unicast+0x700/0x700<br /> __sock_sendmsg+0xc5/0x190<br /> ____sys_sendmsg+0x53f/0x760<br /> ? import_iovec+0x7/0x10<br /> ? kernel_sendmsg+0x30/0x30<br /> ? __copy_msghdr+0x3c0/0x3c0<br /> ? filter_irq_stacks+0x90/0x90<br /> ? stack_depot_save_flags+0x28/0xa30<br /> ___sys_sen<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix null check of pipe_ctx-&gt;plane_state for update_dchubp_dpp<br /> <br /> Similar to commit 6a057072ddd1 ("drm/amd/display: Fix null check for<br /> pipe_ctx-&gt;plane_state in dcn20_program_pipe") that addresses a null<br /> pointer dereference on dcn20_update_dchubp_dpp. This is the same<br /> function hooked for update_dchubp_dpp in dcn401, with the same issue.<br /> Fix possible null pointer deference on dcn401_program_pipe too.<br /> <br /> (cherry picked from commit d8d47f739752227957d8efc0cb894761bfe1d879)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> strlen+0x93/0xa0 lib/string.c:420<br /> __fortify_strlen include/linux/fortify-string.h:268 [inline]<br /> get_kobj_path_length lib/kobject.c:118 [inline]<br /> kobject_get_path+0x3f/0x2a0 lib/kobject.c:158<br /> kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545<br /> ib_register_device drivers/infiniband/core/device.c:1472 [inline]<br /> ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393<br /> rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552<br /> rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550<br /> rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225<br /> nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796<br /> rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195<br /> rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339<br /> netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg net/socket.c:727 [inline]<br /> ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620<br /> __sys_sendmsg+0x16d/0x220 net/socket.c:2652<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> This problem is similar to the problem that the<br /> commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")<br /> fixes.<br /> <br /> The root cause is: the function ib_device_rename() renames the name with<br /> lock. But in the function kobject_uevent(), this name is accessed without<br /> lock protection at the same time.<br /> <br /> The solution is to add the lock protection when this name is accessed in<br /> the function kobject_uevent().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: fix race condition in unaccepted memory handling<br /> <br /> The page allocator tracks the number of zones that have unaccepted memory<br /> using static_branch_enc/dec() and uses that static branch in hot paths to<br /> determine if it needs to deal with unaccepted memory.<br /> <br /> Borislav and Thomas pointed out that the tracking is racy: operations on<br /> static_branch are not serialized against adding/removing unaccepted pages<br /> to/from the zone.<br /> <br /> Sanity checks inside static_branch machinery detects it:<br /> <br /> WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0<br /> <br /> The comment around the WARN() explains the problem:<br /> <br /> /*<br /> * Warn about the &amp;#39;-1&amp;#39; case though; since that means a<br /> * decrement is concurrent with a first (0-&gt;1) increment. IOW<br /> * people are trying to disable something that wasn&amp;#39;t yet fully<br /> * enabled. This suggests an ordering problem on the user side.<br /> */<br /> <br /> The effect of this static_branch optimization is only visible on<br /> microbenchmark.<br /> <br /> Instead of adding more complexity around it, remove it altogether.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: disable napi on driver removal<br /> <br /> A warning on driver removal started occurring after commit 9dd05df8403b<br /> ("net: warn if NAPI instance wasn&amp;#39;t shut down"). Disable tx napi before<br /> deleting it in mt76_dma_cleanup().<br /> <br /> WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100<br /> CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)<br /> Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024<br /> RIP: 0010:__netif_napi_del_locked+0xf0/0x100<br /> Call Trace:<br /> <br /> mt76_dma_cleanup+0x54/0x2f0 [mt76]<br /> mt7921_pci_remove+0xd5/0x190 [mt7921e]<br /> pci_device_remove+0x47/0xc0<br /> device_release_driver_internal+0x19e/0x200<br /> driver_detach+0x48/0x90<br /> bus_remove_driver+0x6d/0xf0<br /> pci_unregister_driver+0x2e/0xb0<br /> __do_sys_delete_module.isra.0+0x197/0x2e0<br /> do_syscall_64+0x7b/0x160<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Tested with mt7921e but the same pattern can be actually applied to other<br /> mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled<br /> in their *_dma_init() functions and only toggled off and on again inside<br /> their suspend/resume/reset paths. So it should be okay to disable tx<br /> napi in such a generic way.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).