Към съдържанието
Търсене

CVE-2026-68469: Linux

Няма оценка

CVSS

Няма данни

Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)

Няма потвърждение

Атакува се

Няма данни

Време до експлоатация

    Описание

    Оригинално описание

    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 a

    Засегнати продукти

    • Linux Linux: 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди 2ed36b2586f16c480ed58de303af704c2235e16d; 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди 5796eabe435d83544b6fe39851ce47ca68fdb778; 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди 31a2c409f8f58d20f0f6391c151421155768ed77; 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди deb5f0ae384f1cf41fccaf6375266db2f2911b2b; 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди 1bc55db2d34756bd53e4460dbb699619ee13cd7f; 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди a59cfa165aee3e29d06145041c0ebe46a51de604; 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди 6126e12bf8c87badeab41a164c9689ac88e5c160; 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e преди d78a407bad6f500884a8606aea1a5a9207be4030
    • Linux Linux: 3.0; преди 3.0; 5.10.261 до 5.10.*; 5.15.212 до 5.15.*; 6.1.178 до 6.1.*; 6.6.145 до 6.6.*; 6.12.97 до 6.12.*; 6.18.40 до 6.18.*; 7.1.5 до 7.1.*; от 7.2 нататък

    История

    • 15 август 2026 Публикувано

    Други уязвимости в Linux Linux

    Първоизточници

    CVE-2026-68469: Linux | freedomonline.bg