CVE-2024-40927
Təsvir
Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: xhci: Çoxsaylı axın halında TD təmizlənməsinin idarə edilməsi Çoxsaylı axın istifadə edildikdə, son nöqtə dayandırıldıqda bir neçə TD emalda ola bilər. Hər biri üçün Set TR Dequeue Pointer buraxmalıyıq ki, hər şeyin düzgün sıfırlandığına və keşlərin təmizləndiyinə əmin olaq. Məntiqi elə dəyişdirin ki, müxtəlif axınlar üçün aktiv tapılan istənilən N>1 TD, birincisi emal edildikdən sonra təxirə salınsın və hamısı ilə işimiz bitənə qədər növbəti əmri növbəyə qoymaq üçün xhci_handle_cmd_set_deq()-dən xhci_invalidate_cancelled_tds() yenidən çağırılsın. Həmçinin xəta/"heç vaxt baş verməməli" yollarını elə dəyişdirin ki, hardware keşini təmizləmək üçün əmr buraxa bilməsək belə, ən azı təsirlənmiş istənilən TD-ni təmizləyək və bu baş verərsə, xhci_warn() ilə yüksək səslə şikayət edək. Bu problem halı XHCI sürücüsünün erkən dövründə, axın dəstəyi ilk əlavə edildiyi zaman e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") commitinə qədər uzanır. Sonra o, 674f8438c121 ("xhci: split handling halted endpoints into two steps") commitində müəyyən edildi, lakin düzəldilmədi və xəbərdarlığa çevrilmədi; həmin commit problem halı üçün FIXME şərhi əlavə etdi (davranışı maddi cəhətdən dəyişmədən, nə qədər görə bilirəmsə, baxmayaraq ki, yeni məntiq problemi daha aşkar etdi). Daha sonra, 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") commitində bu yenidən etiraf edildi. [Mathias: 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") commiti əvvəldə qeyd olunan yamağa hədəflənmiş reqressiya düzəlişi idi. İstifadəçilər UAS cihazlarının unmount/ayrılmasından sonra usb-nin ilişib qalması ilə bağlı problemlər bildirdilər. Bu, çoxsaylı axınların TD təmizlənməsini ilkin vəziyyətinə qaytardı.] Görünür, commit müəllifi problemdən xəbərdar idi (yenə də onu təqdim etməyi seçdi): O, hələ də FIXME kimi qeyd olunurdu, problem vəziyyətini qeyd etmək üçün xhci_dbg() əlavə edilmişdi və qalan məsələ commit təsvirində qeyd olunmuşdu. Bu nöqtədə tamamilə idarə olunmayan və məlum pozulmuş vəziyyət üçün log tipinin xhci_dbg() seçilməsi təəccüblü və təəssüf doğurur, çünki bu, heç bir real istifadəçinin istehsalatda logu görməyəcəyinə zəmanət verir və bununla da onu demək olar ki, sazlana bilməz edir (həqiqətən də, DEBUG-u yandırsanız belə, mesaj ümumiyyətlə problem olduğuna işarə etmir). Nəhayət etibarlı reprodu tapmaq və dərin sazlama sessiyası apara bilmək üçün *aylarla* təsadüfi xHC qəzaları lazım oldu; bütün bunlardan qaçmaq olardı, əgər bu idarə olunmayan, pozulmuş vəziyyət əslində xəbərdarlıqla bildirilsəydi, çünki qəsdən düzəldilməmiş qalmış baq kimi elə olmalı idi (heç demirəm ki, ümumiyyətlə qalmamalı idi). > Ləğv edilmiş TD-lərlə bütün axın halqalarının keşlərinin təmizlənməsini həll etmək üçün başqa bir düzəliş lazımdır, lakin o qədər də təcili deyil. Bu bəyanatdan 3 il və ilkin baq təqdim edildikdən 14 il sonra, düşünürəm ki, nəhayət onu düzəltməyin vaxtıdır. Və bəlkə növbəti dəfə baqları düzəldilməmiş qoymayaq (ki, onlar əslində ilkin baqdan daha pisdir) və gəlin insanları həqiqətən kernel commitlərini nəzərdən keçirməyə cəlb edək, xahiş edirəm. Xətalar/nasazlıqlar idarə edilərkən UAS cihazları ilə xHC qəzalarını və IOMMU nasazlıqlarını düzəldir. Ən asan reprodu `hdparm` ilə diskdə erkən sektoru (məs. 1024) pis kimi işarələmək, sonra dövrədə `cat /dev/sdX > /dev/null` işlətməkdir. Ən azı JMicron nəzarətçiləri halında, oxuma xətaları iki TD-ni ləğv etməli olur (müxtəlif axınlara iki növbəyə qoyulmuş sorğu üçün) və düzgün təmizlənməyən biri, köhnəlmiş TD-lərin istinad etdiyi, artıq xəritədən çıxarılmış DMA səhifələrinə giriş etməyə çalışarkən xHC-ni tamamilə nasaz edir. Bu adətən tez baş verir (iki və ya üç dövrədən sonra). Bu düzəlişdən sonra `cat`-i gecə boyu dövrədə işlək qoydum və heç bir xHC nasazlığı yaşamadım, bütün oxuma xətaları düzgün bərpa olundu. Apple M1 Mac Mini-də (dwc3 host) reprodu edilib və sınaqdan keçirilib. IOMMU olmayan sistemlərdə bu baq əvəzində sərbəst buraxılmış yaddaşı səssizcə korlayardı və bununla da bunu ---kəsilmiş---
Necə düzəltmək olar
- linux linux_kernel5.15.162, 6.1.95, 6.6.35, 6.9.6 və ya daha yeni versiya
Təsirlənən məhsullar
| Məhsul | Təsirlənən versiyalar | Düzəldildiyi versiya |
|---|---|---|
| linux linux_kernel | 2.6.35 ≤ v < 5.15.162, 5.16 ≤ v < 6.1.95, 6.2 ≤ v < 6.6.35, 6.7 ≤ v < 6.9.6, 6.10 | 5.15.162, 6.1.95, 6.6.35, 6.9.6 |
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.