CVE-2026-93209
Təsvir
Linux kernel-də aşağıdakı zəiflik aradan qaldırılmışdır: Bluetooth: hci_core: req_skb üçün skb_clone() əvəzinə skb_get()-dən istifadə edin BT aktivləşdirilməsi fasiləli olaraq -ETIMEDOUT (-110) xətası ilə uğursuz olur. Kernel loqunda HCI Read Local Version əmrinin göndərildiyi və proqram təminatının (firmware) 0x00 statusu ilə cavab verdiyi görünür (hci_req_cmd_complete() BT_DBG tərəfindən qeyd edilmişdir), lakin __hci_cmd_sync_sk() funksiyasındakı gözləyici heç vaxt oyanmır və 10 saniyədən sonra zaman aşımına uğrayır: bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add bluetooth hci0: skb len 4 // hci_cmd_sync_alloc bluetooth hci0: length 1 // hci_req_sync_run Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work Bluetooth: hci0 type 1 len 4 // hci_send_frame Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete <-- req_skb NULL: req_complete_skb təyin edilməyib, hci_cmd_sync_complete() heç vaxt çağırılmır, req_status HCI_REQ_PEND olaraq qalır --> <-- 10 saniyə sonra: wait_event_interruptible_timeout müddəti bitir --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk Problemin kök səbəbi ondan ibarətdir ki, hci_send_cmd_sync() göndərilmiş əmri hdev->req_skb-yə klonlayır ki, hci_req_cmd_complete() qeydiyyatdan keçmiş tamamlanma geri çağırma funksiyasını (callback) tapa bilsin. Yaddaş çatışmazlığı olduqda bu skb_clone() uğursuz olur və hdev->req_skb NULL qalır. Proqram təminatının cavabı alınır və emal edilir, lakin hci_req_cmd_complete() NULL req_skb tapır, buna görə də hci_cmd_sync_complete() heç vaxt çağırılmır, req_status HCI_REQ_PEND olaraq qalır və gözləyici -ETIMEDOUT ilə zaman aşımına uğrayır. req_skb yalnız bt_cb(skb)->hci geri çağırmalarını və opcode-u oxumaq üçün istifadə olunur — o, heç vaxt dəyişdirilmir. skb_clone() funksiyasını skb_get() ilə əvəz edin; bu funksiya yeni yaddaş ayırmadan sadəcə hdev->sent_cmd-nin istinad sayını artırır və buna görə də uğursuz ola bilməz. Bu problem ilk dəfə ttyport_open() uğursuz olduqda ttyport_close()-da use-after-free kimi müşahidə edilmiş və daha əvvəlki yamalar seriyasında [1] araşdırılmışdı. Həmin araşdırma yuxarıda təsvir olunan əsl kök səbəbin aşkar edilməsinə gətirib çıxardı. [1] https://lore.kernel.org/all/[email protected]/
Necə düzəltmək olar
- Linux Linux0337fb092873a4146aa854acb554675b49c8f6b5, d5eef0747071934a1c080ee617fa4fd3566394c5, d7723320db4c9cb9ec2b9a36140e6c641dd77814, d0b28e9655f4b3195210627577f81883dc1d0162, 26f66d5b8a5663af498f7ccc94fc79fb47a2191f, f5afdff569a09d1cb8cf19826199d024725576cb, 6.1.118, 6.6.157, 6.8, 6.9 və ya daha yeni versiya
Təsirlənən məhsullar
| Məhsul | Təsirlənən versiyalar | Düzəldildiyi versiya |
|---|---|---|
| Linux Linux | da77c1d39bc527b31890bfa0405763c82828defb ≤ v < 0337fb092873a4146aa854acb554675b49c8f6b5, 2af7aa6685e22d0dc546b0d27e5f16d3afe211fa ≤ v < d5eef0747071934a1c080ee617fa4fd3566394c5, 2615fd9a7c2507eb3be3fbe49dcec88a2f56454a ≤ v < d7723320db4c9cb9ec2b9a36140e6c641dd77814, 2615fd9a7c2507eb3be3fbe49dcec88a2f56454a ≤ v < d0b28e9655f4b3195210627577f81883dc1d0162, 2615fd9a7c2507eb3be3fbe49dcec88a2f56454a ≤ v < 26f66d5b8a5663af498f7ccc94fc79fb47a2191f, 2615fd9a7c2507eb3be3fbe49dcec88a2f56454a ≤ v < f5afdff569a09d1cb8cf19826199d024725576cb, 4ff121be63b761950610f422437aaaef8e075c40, 18a4c59af609994552c8b39c5438304e070e55c7, 6.1.83 ≤ v < 6.1.118, 6.6.23 ≤ v < 6.6.157, 6.7.11 ≤ v < 6.8, 6.8.2 ≤ v < 6.9, 6.9 | 0337fb092873a4146aa854acb554675b49c8f6b5, d5eef0747071934a1c080ee617fa4fd3566394c5, d7723320db4c9cb9ec2b9a36140e6c641dd77814, d0b28e9655f4b3195210627577f81883dc1d0162, 26f66d5b8a5663af498f7ccc94fc79fb47a2191f, f5afdff569a09d1cb8cf19826199d024725576cb, 6.1.118, 6.6.157, 6.8, 6.9 |
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.