CVE-2023-54288
Description
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fortify the spinlock against deadlock by interrupt
In the function ieee80211_tx_dequeue() there is a particular locking sequence:
begin: spin_lock(&local->queue_stop_reason_lock); q_stopped = local->queue_stop_reasons[q]; spin_unlock(&local->queue_stop_reason_lock);
However small the chance (increased by ftracetest), an asynchronous interrupt can occur in between of spin_lock() and spin_unlock(), and the interrupt routine will attempt to lock the same &local->queue_stop_reason_lock again.
This will cause a costly reset of the CPU and the wifi device or an altogether hang in the single CPU and single core scenario.
The only remaining spin_lock(&local->queue_stop_reason_lock) that did not disable interrupts was patched, which should prevent any deadlocks on the same CPU/core and the same wifi device.
This is the probable trace of the deadlock:
kernel: ================================ kernel: WARNING: inconsistent lock state kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W kernel: -------------------------------- kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes: kernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40 kernel: {IN-SOFTIRQ-W} state was registered at: kernel: lock_acquire+0xc7/0x2d0 kernel: _raw_spin_lock+0x36/0x50 kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211] kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm] kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm] kernel: ieee80211_queue_skb+0x450/0x730 [mac80211] kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211] kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211] kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211] kernel: dev_hard_start_xmit+0xb5/0x260 kernel: __dev_queue_xmit+0xdbe/0x1200 kernel: neigh_resolve_output+0x166/0x260 kernel: ip_finish_output2+0x216/0xb80 kernel: __ip_finish_output+0x2a4/0x4d0 kernel: ip_finish_output+0x2d/0xd0 kernel: ip_output+0x82/0x2b0 kernel: ip_local_out+0xec/0x110 kernel: igmpv3_sendpack+0x5c/0x90 kernel: igmp_ifc_timer_expire+0x26e/0x4e0 kernel: call_timer_fn+0xa5/0x230 kernel: run_timer_softirq+0x27f/0x550 kernel: __do_softirq+0xb4/0x3a4 kernel: irq_exit_rcu+0x9b/0xc0 kernel: sysvec_apic_timer_interrupt+0x80/0xa0 kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30 kernel: _raw_spin_unlock_irqrestore+0x3f/0x70 kernel: free_to_partial_list+0x3d6/0x590 kernel: __slab_free+0x1b7/0x310 kernel: kmem_cache_free+0x52d/0x550 kernel: putname+0x5d/0x70 kernel: do_sys_openat2+0x1d7/0x310 kernel: do_sys_open+0x51/0x80 kernel: __x64_sys_openat+0x24/0x30 kernel: do_syscall_64+0x5c/0x90 kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc kernel: irq event stamp: 5120729 kernel: hardirqs last enabled at (5120729): [] trace_graph_return+0xd6/0x120 kernel: hardirqs last disabled at (5120728): [] trace_graph_return+0xf0/0x120 kernel: softirqs last enabled at (5069900): [] return_to_handler+0x0/0x40 kernel: softirqs last disabled at (5067555): [] return_to_handler+0x0/0x40 kernel: other info that might help us debug this: kernel: Possible unsafe locking scenario: kernel: CPU0 kernel: ---- kernel: lock(&local->queue_stop_reason_lock); kernel: kernel: lock(&local->queue_stop_reason_lock); kernel: * DEADLOCK * kernel: 8 locks held by kworker/5:0/25656: kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530 kernel: #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530 kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40 kernel: #3: ffff9d619 ---truncated---
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A missing IRQ-disabling spinlock in Linux kernel's mac80211 ieee80211_tx_dequeue() can cause a deadlock when an interrupt tries to acquire the same lock on the same CPU.
Root
Cause
The vulnerability is a locking deficiency in the Linux kernel's mac80211 subsystem, specifically in the ieee80211_tx_dequeue() function. The function acquires the &local->queue_stop_reason_lock with spin_lock() without disabling local interrupts. If an interrupt occurs after the lock is taken but before it is released, the interrupt handler may attempt to acquire the same spinlock, leading to a classic deadlock on a single CPU [1].
Exploitation
Scenario
An attacker does not directly trigger this bug from userspace. The deadlock can be triggered by a race condition that is more likely to occur under specific workloads or testing tools like ftracetest, which increase the frequency of interrupts [1]. The attacker would need to be able to influence network traffic or system state such that an interrupt occurs during the critical section, but no special privileges or authentication are required beyond the ability to generate network activity that flows through the mac80211 stack.
Impact
If the deadlock occurs, the CPU will spin indefinitely, causing a system hang or a costly reset of the CPU and the Wi-Fi device. On single-core or single-CPU systems, this can result in a complete system lockup [1].
Mitigation
The fix, committed to the Linux kernel, replaces the plain spin_lock() with spin_lock_irqsave() in the remaining instance that did not disable interrupts, ensuring that the lock is always taken with interrupts disabled and preventing the deadlock [1]. Users should apply the kernel patch (commit 6df3eafa31b3) or update to a kernel version containing the fix.
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
3c79d794a2cd76df3eafa31b3ef6e1997da63Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.