CVE-2026-89732

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: usb: gadget: f_fs: ep0 oxuma dövrü zamanı deadlock-un qarşısının alınması Hazırda ffs_ep0_read() funksiyası hadisəni gözləyərək yuxuya getməyə hazırlaşarkən ffs->mutex kilidini saxlayır. Heç bir quraşdırma (setup) hadisəsi gözlənilmədikdə, o, mutex hələ də tutulmuş halda wait_event_interruptible_exclusive_locked_irq() funksiyasını çağırır. Gözləmə makrosu yuxuya getməzdən əvvəl waitqueue spinlock-unu qəsdən buraxır, lakin mutex-i buraxmır. Əgər istifadəçi sahəsi (userspace) demonu read() vasitəsilə ep0-nı sorğulayırsa və gadget configfs vasitəsilə asinxron şəkildə sökülürsə (məsələn, echo "" > UDC), deadlock baş verə bilər: 1. Configfs sökülməsi FUNCTIONFS_UNBIND hadisəsini növbəyə düzən functionfs_unbind() funksiyasını çağırır. 2. Demon oyanır, hadisəni emal edir və mutex-i buraxır. 3. Lakin, əgər demon çıxış etməzdən əvvəl dövrə girib dərhal növbəti read() sorğusunu göndərərsə, o, ffs->mutex-i yenidən əldə edir və yenidən kəsilə bilən (interruptible) yuxuya gedir. 4. Bu arada, functionfs_unbind() icranı davam etdirir və ep0req-i sökmək üçün ffs->mutex-i əldə etməyə çalışır. 5. Nüvədə deadlock yaranır, çünki configfs axını mutex-i gözləyərək kəsilə bilməyən (uninterruptible) yuxuda qalır, istifadəçi sahəsi demonu isə artıq heç bir hadisə gəlməyəcəyi üçün mutex-i sonsuz müddətə tutaraq kəsilə bilən yuxuda qalır. Bunu düzəltmək üçün yuxuya getməzdən əvvəl həm waitqueue spinlock-unu, həm də ffs->mutex-i buraxırıq və bunun əvəzinə wait_event_interruptible_exclusive() funksiyasından istifadə edirik. Oyanarkən, mutex-i təhlükəsiz şəkildə yenidən əldə etmək və vəziyyət maşınını (state machine) yenidən qiymətləndirmək üçün `retry` etiketine geri qayıdırıq. ffs->mutex tutulmuş halda yuxuya getməməklə, biz gadget sökülmələrini (hansı ki, mutex tələb edir) istifadəçi sahəsi sorğularından təbii şəkildə ayırırıq.