CVE-2026-68469
Təsvir
Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: wifi: mwifiex: çox sayda roam iterasiyalarından sonra daim məşğul olan skanların düzəldilməsi Firmware-in yuxu rejiminə keçməsi üçün drayver əvvəllər alınmış yuxu sorğusunu təsdiqləməlidir. Hadisələrin normal ardıcıllığı belədir: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. sleep-confirm əmrini göndərməzdən əvvəl drayver icra olunan və ya tamamlanmağı gözləyən heç bir əmrin olmadığından əmin olmalıdır. mwifiex_ret_802_11_associate() funksiyası assosiasiya əmri cavabını emal edərkən, normal enerji qənaəti idarəetmə axınından kənar şəkildə şərtsiz olaraq ps_state = PS_STATE_AWAKE təyin edir. Əgər assosiasiya əmri icra olunarkən EVENT_SLEEP gələrsə, assosiasiya əmri cavabı analiz edilərkən ps_state PRE_SLEEP olur və məcburi AWAKE onu overwrite edir. Təxirə salınmış sleep-confirm heç vaxt göndərilmir. Növbəti scan_start əmri düzgün şəkildə təsdiqlənir, lakin firmware scan_result hadisələrini yaratmır. Skan sorğusu heç vaxt başa çatmır və istifadəçi sahəsindən (userspace) gələn əlavə sorğular -EBUSY xətası ilə uğursuz olur. Həm IW412, həm də W8997 üzərində sınaqlar apardıqdan sonra mən bu xətanı yalnız IW412-də tetikləyə bildim və firmware-lərin fərqli davrandığını müşahidə etdim. IW412-də autentifikasiya / assosiasiya prosesi davam edərkən firmware hələ də EVENT_SLEEP göndərir. Eyni şərait altında W8997 assosiasiya müddətində enerji qənaətini bloklayır kimi görünür, buna görə də aşağıda təsvir olunan dövrü sınaqlar zamanı uzun müddət (>12 saat) yoxlasam belə, PRE_SLEEP heç vaxt assosiasiya cavabı ilə üst-üstə düşmədi. IW412-də EVENT_SLEEP-i tetikləyən əmrlər arasındakı gecikmənin empirik olaraq ~20ms olduğu müəyyən edilmişdir. Bu gecikmə drayver sazlama məlumatlarını çıxararkən (debug_mask = 0x00000037) təbii şəkildə baş verə bilər ki, bu vəziyyətdə aşağıda təsvir olunan "test 1)" işlədildikdə məşğul skan problemi təkrar istehsal olunur. Əmrlər arasındakı gecikmə ~20ms-dən az olduqda, firmware oyaq qalır və eyni testi işlədərkən problem təkrar istehsal olunmadı. host_mlme=false yolu da fərqli davranır. Bu halda bütün autentifikasiya / assosiasiya tranzaksiyası bir əmr (HostCmd_CMD_802_11_ASSOCIATE) vasitəsilə icra edilir və əmr işləyərkən firmware EVENT_SLEEP yaymır. Təyinatı silin, beləliklə ps_state yalnız enerji qənaəti hadisələrinin idarə edilməsi ilə bağlı yollarda və düzgün yuxu təsdiqi üçün əsas iş növbəsində (workqueue) manipulyasiya edilsin. Aşağıdakı dövrü sınaqlar yerinə yetirilmişdir (debug çıxışı aktiv edilmiş halda): 1) İki AP arasında (biri 5GHz, biri 2.4GHz, eyni SSID) məcburi roaming; roaming davranışını tetikləmək üçün wpa_cli istifadə edilmiş, iterasiyalar arasında 2 saniyə fasilə verilmişdir. 2) AP 1-dən məcburi ayrılma və AP 2-yə qoşulma, skanın yoxlanılması; qoşulma dəyişikliklərini tetikləmək üçün wpa_cli istifadə edilmiş, iterasiyalar arasında 2 saniyə fasilə verilmişdir. Hər bir test hər cihazda ən azı 3 saat ərzində işlədilmişdir.
Necə düzəltmək olar
- Linux Linux2ed36b2586f16c480ed58de303af704c2235e16d, 5796eabe435d83544b6fe39851ce47ca68fdb778, 31a2c409f8f58d20f0f6391c151421155768ed77, deb5f0ae384f1cf41fccaf6375266db2f2911b2b, 1bc55db2d34756bd53e4460dbb699619ee13cd7f, a59cfa165aee3e29d06145041c0ebe46a51de604, 6126e12bf8c87badeab41a164c9689ac88e5c160, d78a407bad6f500884a8606aea1a5a9207be4030 və ya daha yeni versiya
Təsirlənən məhsullar
| Məhsul | Təsirlənən versiyalar | Düzəldildiyi versiya |
|---|---|---|
| Linux Linux | 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < 2ed36b2586f16c480ed58de303af704c2235e16d, 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < 5796eabe435d83544b6fe39851ce47ca68fdb778, 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < 31a2c409f8f58d20f0f6391c151421155768ed77, 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < deb5f0ae384f1cf41fccaf6375266db2f2911b2b, 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < 1bc55db2d34756bd53e4460dbb699619ee13cd7f, 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < a59cfa165aee3e29d06145041c0ebe46a51de604, 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < 6126e12bf8c87badeab41a164c9689ac88e5c160, 5e6e3a92b9a4c9416b17f468fa5c7fa2233b8b4e ≤ v < d78a407bad6f500884a8606aea1a5a9207be4030, 3.0 | 2ed36b2586f16c480ed58de303af704c2235e16d, 5796eabe435d83544b6fe39851ce47ca68fdb778, 31a2c409f8f58d20f0f6391c151421155768ed77, deb5f0ae384f1cf41fccaf6375266db2f2911b2b, 1bc55db2d34756bd53e4460dbb699619ee13cd7f, a59cfa165aee3e29d06145041c0ebe46a51de604, 6126e12bf8c87badeab41a164c9689ac88e5c160, d78a407bad6f500884a8606aea1a5a9207be4030 |
Versiyanızı yoxlayın
Məhsulu seçin və istifadə etdiyiniz versiyanı yazın; versiyanın təsirlənən aralıqda olub-olmadığını görün.
Attack Surface Management
Domenlərinizə bağlı aktivləri, onlarda işləyən texnologiyaları və məlum zəiflikləri bir siyahıda görün.