CVE-2026-23130: wifi: ath12k: fix dead lock while flushing management frames
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix dead lock while flushing management frames
Commit [1] converted the management transmission work item into a wiphy work. Since a wiphy work can only run under wiphy lock protection, a race condition happens in below scenario:
1. a management frame is queued for transmission. 2. ath12kmacopflush() gets called to flush pending frames associated with the hardware (i.e, vif being NULL). Then in ath12kmacflush() the process waits for the transmission done. 3. Since wiphy lock has been taken by the flush process, the transmission work item has no chance to run, hence the dead lock.
From user view, this dead lock results in below issue:
wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticated wlp8s0: associate with xxxxxx (try 1/3) wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTHLEAVING) ath12kpci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1
The dead lock can be avoided by invoking wiphyworkflush() to proactively run the queued work item. Note actually it is already present in ath12kmacopflush(), however it does not protect the case where vif being NULL. Hence move it ahead to cover this case as well.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPLV1.0V2.0SILICONZ-1.115823.3
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux systems using the ath12k Wi-Fi driver are implicated when pending management frames are flushed for the hardware, including flushes where the virtual interface is NULL. The issue affects management-frame transmission handling rather than all networking operations.
What access is needed to trigger the vulnerability?
The CVSS vector indicates local access with low privileges and no user interaction is required. Its stated impact is availability only, with high availability impact and no confidentiality or integrity impact.
How can I tell whether this is occurring?
Affected systems may repeatedly attempt authentication or association and then abort the association locally. Kernel logs can include "failed to flush mgmt transmit queue, mgmt pkts pending 1" from ath12k_pci.
What remediation is available?
A patch is available. The fix avoids the deadlock by changing how the management transmission work is invoked during flushing.