CVE-2025-38311

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: iavf: crit lock-dan imtina edin Crit lock-dan imtina edilir. Bu bizi səhvlərə meyilli try_locks məntiqindən azad edir. Jakub tərəfindən təqdim edilən netdev_lock() sayəsində bu artıq asandır və əksər hallarda biz onsuz da onunla qorunurduq - bunun belə olmadığı hallarda crit lock, netdev lock ilə əvəz edildi. Lockdep bildirir ki, biz işi crit_lock altında ləğv etməliyik [splat1] və Slawomir tərəfindən [1]-dən bəri əsasən bu sxemə əməl etmişik. Lakin bu yerinə yetiriləndə belə, hələ də ölü kilidlənmələr (deadlocks) baş verirdi [splat2]. Buna görə də biz daha böyük problemə, yəni iavf-nin "qəribə kilidləmə/planlaşdırma" (weird locking/scheduling) məsələsinə baxmalıyıq. Bunu düzəltmək üçün ilk addım crit lock-u silməkdir. Mən planlaşdırmanı/tapşırıqları sadələşdirən bir -next seriyası ilə davam edəcəyəm. [Splat2]-ni düzəltmək üçün (əgər crit lock-u saxlasaydıq, bu tamamilə çirkin olardı) işi netdev lock olmadan ləğv edin (qəribə unlock+lock sxemi). Daha çox işin planlaşdırılmasını daxil etmək üçün iavf_watchdog_task()-ın qorunan hissəsini genişləndirin. Qeyd edin ki, iavf_reset_task()-da silinmiş şərh yanlış yerləşdirilmişdi, o, silinmiş if şərtinin daxilinə aid idi, buna görə də indi silindi. [splat1] - bu yamasız - VF silinməsi zamanı ölü kilidlənmə: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock. [splat2] - iş crit lock altında ləğv edilərkən, bu seriya olmadan, müvəqqəti həll cəhdinə baxmaq üçün [2]: WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock. [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a