CVE-2026-23130
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk0th percentile - higher than 0% of all known CVEs
Summary
In the Linux kernel, the wifi ath12k driver has a deadlock while flushing management frames. After management transmission was converted to a wiphy work, ath12k_mac_op_flush() called with a NULL vif holds the wiphy lock, preventing the queued transmission work from running. This results in failed authentication/association and a 'failed to flush mgmt transmit queue' error.
Risk Assessment
Organizations using ath12k-based Wi-Fi cards (e.g., WCN7850) may experience unstable Wi-Fi connectivity, failed authentication and association attempts, and stalls in management frame handling. This can lead to network connectivity loss and service disruptions.
Recommendation
Update the Linux kernel to a version containing the fix for CVE-2026-23130 (moving wiphy_work_flush() ahead to cover the NULL vif case in ath12k_mac_op_flush()). Until patched, consider limiting use of affected Wi-Fi cards in critical systems.
Other vulnerabilities in Linux kernel ath12k driver
See all- CVE-2025-38606Medium
In the Linux kernel, the ath12k Wi-Fi driver accesses an uninitialized arvif->ar pointer during beacon miss handling. This occurs for P2P interfaces that have their radio object detached after scan completion, leading to a NULL pointer dereference and kernel crash (KASAN: null-ptr-deref).
- CVE-2025-37743Medium
In the Linux kernel, the wifi ath12k driver has a memory leak when enabling extended statistics mode. The driver allocates a mon_mpdu object while handling the HAL_RX_MPDU_START TLV but does not free it when only extended statistics mode is active (without standalone monitor mode).
Original NVD description (English source)
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. ath12k_mac_op_flush() gets called to flush pending frames associated with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush() 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=DEAUTH_LEAVING) ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1 The dead lock can be avoided by invoking wiphy_work_flush() to proactively run the queued work item. Note actually it is already present in ath12k_mac_op_flush(), 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-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Vulnerability data from NVD (NIST) · CISA KEV · EPSS