CVE-2026-23130

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix dead lock while flushing management frames<br /> <br /> Commit [1] converted the management transmission work item into a<br /> wiphy work. Since a wiphy work can only run under wiphy lock<br /> protection, a race condition happens in below scenario:<br /> <br /> 1. a management frame is queued for transmission.<br /> 2. ath12k_mac_op_flush() gets called to flush pending frames associated<br /> with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()<br /> the process waits for the transmission done.<br /> 3. Since wiphy lock has been taken by the flush process, the transmission<br /> work item has no chance to run, hence the dead lock.<br /> <br /> &gt;From user view, this dead lock results in below issue:<br /> <br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticate with xxxxxx (local address=xxxxxx)<br /> wlp8s0: send auth to xxxxxx (try 1/3)<br /> wlp8s0: authenticated<br /> wlp8s0: associate with xxxxxx (try 1/3)<br /> wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)<br /> ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1<br /> <br /> The dead lock can be avoided by invoking wiphy_work_flush() to proactively<br /> run the queued work item. Note actually it is already present in<br /> ath12k_mac_op_flush(), however it does not protect the case where vif<br /> being NULL. Hence move it ahead to cover this case as well.<br /> <br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3