CVE-2026-23130

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

A deadlock can occur in the ath12k management frame transmit flush path after the driver converted its management transmit worker into a wiphy work item. A wiphy work item can only execute while holding the wiphy lock. The flush operation takes the wiphy lock and then waits for pending management frame transmissions to complete. In the hardware wide flush case where vif is NULL the code previously did not flush the queued wiphy work before entering the wait loop. Because the wiphy lock is held by the flushing thread the management transmit work cannot run. As a result the pending management packet never completes and the flush waits indefinitely. This manifests as connection failures and timeouts with management packets stuck in the transmit queue. This ensures that queued management transmit work is proactively executed and the flush can observe completion. The impact is primarily denial of service of the wireless interface due to a driver hang.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.