CVE-2022-50202
Təsvir
Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: PM: hibernate: hibernasiyadan bərpa zamanı cihazın yoxlanılmasını (probing) təxirə salmaq syzbot, probe_count dəyişənini əhatə edən AB-BA deadloqunun yarış pəncərəsi olduğu üçün misc_open() [1] funksiyasında asılı qalmış tapşırıq (hung task) barədə məlumat verir. Hazırda, əgər probe_count 0 ola bilmirsə, misc_mtx tutulmuş halda misc_open() -> snapshot_open() -> wait_for_device_probe() sonsuz müddətə yata bilər. Bir cihaz hub_event() iş funksiyası tərəfindən yoxlanıldıqda, probe_count yoxlama funksiyası başlamazdan əvvəl artırılır və yoxlama funksiyası tamamlandıqdan sonra azaldılır. probe_count-un 0-a düşməsinə mane ola biləcək üç hal mövcuddur: (a) Yoxlanılan cihazın cavab verməyi dayandırması (məsələn, xarab və ya zərərli aparat təminatı). (b) /dev/raw-gadget interfeysindən istifadə edərək USB cihazını simulyasiya edən prosesin hansısa səbəbdən cavab verməyi dayandırması. (c) Mövcud cihaz yoxlama sorğuları tamamlanmamış yeni cihaz yoxlama sorğularının gəlməyə davam etməsi. syzbot-un bildirdiyi hadisə (b) halıdır. system_transition_mutex və misc_mtx-i tutan bir proses wait_for_device_probe() daxilində probe_count-un 0 olmasını gözləyir, lakin hub_event() iş funksiyasından çağırılan yoxlama funksiyası mutex_lock(&misc_mtx)-də bloklanmış proseslərin /dev/raw-gadget interfeysi vasitəsilə cavab verməsini gözləyir. Bu yamla, wait_for_device_probe() funksiyasının çağırılması snapshot_open()-dən snapshot_write() və snapshot_ioctl()-ə keçirməklə (b) halı yumşaldılır. Nəzərə alın ki, /dev/raw-gadget interfeysi vasitəsilə USB cihazını simulyasiya edən hər hansı bir axın kəsilməz bloklayıcı əməliyyatlar (məsələn, mutex_lock()) tərəfindən bloklana bildiyi müddətcə (b) ehtimalı qalır. Həmçinin qeyd edək ki, (a) və (c) halları həll edilməmişdir. (c) ilə bağlı, kodu yalnız hibernasiyadan bərpa üçün obrazı ehtiva edən bir cihazı gözləyəcək şəkildə dəyişməliyik. (a) halını necə həll etməli olduğumu bilmirəm, çünki wait_for_device_probe() üçün vaxt limitinin (timeout) istifadəsi obrazdakı istifadəçi məlumatlarının itirilməsinə səbəb ola bilər. Bəlkə biz userland-dan /dev/snapshot interfeysini açmazdan əvvəl obraz cihazını gözləməsini tələb etməliyik.
Necə düzəltmək olar
- linux linux_kernel4.14.291, 4.19.256, 5.4.211, 5.10.137, 5.15.61, 5.18.18, 5.19.2 və ya daha yeni versiya
- git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570
- git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8
- git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50
- git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb
- git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59
- git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91
- git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258
- git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f
Təsirlənən məhsullar
| Məhsul | Təsirlənən versiyalar | Düzəldildiyi versiya |
|---|---|---|
| linux linux_kernel | v < 4.14.291, 4.15 ≤ v < 4.19.256, 4.20 ≤ v < 5.4.211, 5.5 ≤ v < 5.10.137, 5.11 ≤ v < 5.15.61, 5.16 ≤ v < 5.18.18, 5.19 ≤ v < 5.19.2 | 4.14.291, 4.19.256, 5.4.211, 5.10.137, 5.15.61, 5.18.18, 5.19.2 |
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.