CVE-2026-68469 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: fix permanently busy scans after multiple roam iterations
In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed.
mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent.
A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY.
After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours).
On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running "test 1)" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test.
The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running.
Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation.
The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations.
Each test ran in each device for at least 3 hours.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the linux kernel's mwifiex wireless driver component where improper power management state handling leads to persistent scan blocking conditions. The issue stems from a race condition in the powersave state transition mechanism that occurs during wireless association processes, specifically when multiple roaming iterations are performed. The root cause is found in the mwifiex_ret_802_11_associate() function which unconditionally sets ps_state = PS_STATE_AWAKE without proper synchronization with the power management workflow. This behavior overrides the legitimate PRE_SLEEP state that occurs when firmware receives sleep requests during active association operations, preventing the necessary sleep-confirm command from being sent to the hardware.
The technical flaw manifests as a violation of the expected powersave protocol sequence where EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. When an association command is in flight and EVENT_SLEEP arrives, the driver's state management becomes corrupted because the forced AWAKE state overwrites the PRE_SLEEP state that should be preserved until all pending commands complete. This creates a permanent busy state where subsequent scan operations cannot proceed properly and additional requests from userspace fail with -EBUSY error codes.
The operational impact of this vulnerability is significant for wireless network reliability and system stability, particularly in environments requiring frequent roaming or dynamic connection management. The issue affects specific hardware variants including IW412 and W8997 chipsets where firmware behavior differs substantially. On IW412 devices, the bug is consistently reproducible through forced roaming between 5GHz and 2.4GHz access points with identical SSIDs, while W8997 devices appear to suppress power-save during association periods, making them immune to this particular race condition. The vulnerability can be triggered by command delays of approximately 20 milliseconds, which commonly occurs during debugging operations when debug_mask = 0x00000037 is enabled.
The attack surface extends beyond simple connectivity issues to potentially cause complete wireless interface lockups and denial of service conditions in mobile or embedded systems relying on wireless management. This vulnerability maps directly to CWE-691, which addresses insufficient control flow management, and aligns with ATT&CK technique T1547.001 for hijacking system processes through kernel-level modifications. The issue is particularly concerning because it affects the fundamental powersave mechanisms that allow wireless devices to conserve battery power while maintaining connectivity. Testing procedures involving repeated roaming operations between different frequency bands clearly demonstrate the race condition's reproducibility, with each test iteration requiring multiple hours of continuous execution to confirm the persistent busy state behavior.
The fix implemented addresses this by removing the unconditional ps_state assignment within the association processing path and ensuring that power management state transitions only occur through proper powersave event handling mechanisms. This modification ensures that sleep-confirm commands are properly sent to the firmware regardless of whether association operations are in progress, thereby restoring normal scan operation capabilities and preventing the permanent busy state that prevents subsequent wireless operations from completing successfully. The solution maintains proper synchronization with the main workqueue for correct sleep confirmation while preserving all legitimate power management behaviors across different hardware variants.