{"id":"CVE-2026-68469","summary":"wifi: mwifiex: fix permanently busy scans after multiple roam iterations","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: fix permanently busy scans after multiple roam iterations\n\nIn order for the firmware to sleep, the driver has to confirm a\npreviously received sleep request. The normal sequence of evets goes\nlike this:\nEVENT_SLEEP -\u003e adapter-\u003eps_state = PS_STATE_PRE_SLEEP -\u003e sleep-confirm\n-\u003e SLEEP -\u003e EVENT_AWAKE -\u003e AWAKE.\nBefore sending the sleep-confirm command, the driver must make sure\nthere are no commands either running or waiting to be completed.\n\nmwifiex_ret_802_11_associate() unconditionally sets\nps_state = PS_STATE_AWAKE when it processes the association command\nresponse, outside of the normal powersave management flow. If\nEVENT_SLEEP arrives while the association command is in flight,\nps_state is PRE_SLEEP when the association command response is parsed,\nand the forced AWAKE overwrites it. The deferred sleep-confirm is\nnever sent.\n\nA subsequent scan_start command is correctly acknowledged, but the\nfirmware doesn't generate scan_result events. The scan request never\nfinishes, and additional requests from userspace fail with -EBUSY.\n\nAfter testing on both IW412 and W8997, I could only trigger the bug on\nthe IW412 and observed the firmwares behave differently. On the IW412\nthe firmware still sends EVENT_SLEEP while the authentication /\nassociation process is ongoing. A W8997 under the same\nconditions seems to suppress power-save for the duration of the\nassociation, so PRE_SLEEP never coincided with the association response\neven after extended periods of testing using the loops\ndescribed below (\u003e12hours).\n\nOn the IW412, the delay between commands that triggers an EVENT_SLEEP\nwas empirically determined to be ~20ms. This delay can naturally occur\nwhen the driver is outputting debugging information\n(debug_mask = 0x00000037), in which situation the busy scans issue is\nrepeatable while running \"test 1)\" as described below. If the delay\nbetween commands is less than ~20ms, the firmware stays awake and\nthe issue was not reproducible running the same test.\n\nThe host_mlme=false path also behaves differently. In this case, the\nentire authentication / association transaction is executed by one\ncommand (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit\nEVENT_SLEEP while the command is running.\n\nRemove the assignment so the ps_state is only manipulated in the paths\nthat are related to powersave event handling and on the main workqueue\nfor correct sleep confirmation.\n\nThe following loop tests were performed (with debugging output enabled):\n1) force roaming between two AP's, one 5GHz and one 2.4GHz, same\nSSID. Use wpa_cli to trigger the roaming behavior, sleep 2s\nbetween iterations.\n2) force a disconnection to AP 1 and a connection to AP 2, test\nscan. Use wpa_cli to trigger the connection changes, sleep 2s\nbetween iterations.\n\nEach test ran in each device for at least 3 hours.","modified":"2026-08-16T03:48:30.214922278Z","published":"2026-08-15T05:51:27.429Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68469.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/1bc55db2d34756bd53e4460dbb699619ee13cd7f"},{"type":"WEB","url":"https://git.kernel.org/stable/c/2ed36b2586f16c480ed58de303af704c2235e16d"},{"type":"WEB","url":"https://git.kernel.org/stable/c/31a2c409f8f58d20f0f6391c151421155768ed77"},{"type":"WEB","url":"https://git.kernel.org/stable/c/5796eabe435d83544b6fe39851ce47ca68fdb778"},{"type":"WEB","url":"https://git.kernel.org/stable/c/6126e12bf8c87badeab41a164c9689ac88e5c160"},{"type":"WEB","url":"https://git.kernel.org/stable/c/a59cfa165aee3e29d06145041c0ebe46a51de604"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d78a407bad6f500884a8606aea1a5a9207be4030"},{"type":"WEB","url":"https://git.kernel.org/stable/c/deb5f0ae384f1cf41fccaf6375266db2f2911b2b"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68469.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68469"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e"},{"fixed":"2ed36b2586f16c480ed58de303af704c2235e16d"},{"fixed":"5796eabe435d83544b6fe39851ce47ca68fdb778"},{"fixed":"31a2c409f8f58d20f0f6391c151421155768ed77"},{"fixed":"deb5f0ae384f1cf41fccaf6375266db2f2911b2b"},{"fixed":"1bc55db2d34756bd53e4460dbb699619ee13cd7f"},{"fixed":"a59cfa165aee3e29d06145041c0ebe46a51de604"},{"fixed":"6126e12bf8c87badeab41a164c9689ac88e5c160"},{"fixed":"d78a407bad6f500884a8606aea1a5a9207be4030"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68469.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.0.0"},{"fixed":"5.10.261"}]},{"type":"ECOSYSTEM","events":[{"introduced":"5.11.0"},{"fixed":"5.15.212"}]},{"type":"ECOSYSTEM","events":[{"introduced":"5.16.0"},{"fixed":"6.1.178"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.6.145"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.12.97"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.40"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.5"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68469.json"}}],"schema_version":"1.9.0"}