CVE-2026-68469: wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2026-68469 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 5.10.261 with commit 2ed36b2586f16c480ed58de303af704c2235e16d
	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 5.15.212 with commit 5796eabe435d83544b6fe39851ce47ca68fdb778
	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 6.1.178 with commit 31a2c409f8f58d20f0f6391c151421155768ed77
	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 6.6.145 with commit deb5f0ae384f1cf41fccaf6375266db2f2911b2b
	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 6.12.97 with commit 1bc55db2d34756bd53e4460dbb699619ee13cd7f
	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 6.18.40 with commit a59cfa165aee3e29d06145041c0ebe46a51de604
	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 7.1.5 with commit 6126e12bf8c87badeab41a164c9689ac88e5c160
	Issue introduced in 3.0 with commit 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e and fixed in 7.2-rc4 with commit d78a407bad6f500884a8606aea1a5a9207be4030

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-68469
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/net/wireless/marvell/mwifiex/join.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/2ed36b2586f16c480ed58de303af704c2235e16d
	https://git.kernel.org/stable/c/5796eabe435d83544b6fe39851ce47ca68fdb778
	https://git.kernel.org/stable/c/31a2c409f8f58d20f0f6391c151421155768ed77
	https://git.kernel.org/stable/c/deb5f0ae384f1cf41fccaf6375266db2f2911b2b
	https://git.kernel.org/stable/c/1bc55db2d34756bd53e4460dbb699619ee13cd7f
	https://git.kernel.org/stable/c/a59cfa165aee3e29d06145041c0ebe46a51de604
	https://git.kernel.org/stable/c/6126e12bf8c87badeab41a164c9689ac88e5c160
	https://git.kernel.org/stable/c/d78a407bad6f500884a8606aea1a5a9207be4030