CVE-2026-80825

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: wifi: mt76: mt7925: usb_sdio_tx_prepare_skb funksiyasında tx headroom-un təmin edilməsi mt7925_usb_sdio_tx_prepare_skb() hər bir skb-yə TX deskriptoru və USB başlığı əlavə edir və onlar üçün lazımi boşluğun (headroom) artıq mövcud olduğunu fərz edir. Bu, mac80211 tərəfindən hw->extra_tx_headroom rezerv edildiyi lokal trafik üçün keçərlidir, lakin yönləndirilmiş kadrlar ieee80211_8023_xmit() vasitəsilə göndərilir və burada həmin boşluq rezerv edilmir. Simli interfeysi mt7925u AP-yə körpüləndirdikdə (bridge), daxil olan ilk kifayət qədər boşluğu olmayan yönləndirilmiş kadr nüvənin çökməsinə (kernel panic) səbəb olur: skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skb_panic+0x58/0x60 (P) skb_push+0x58/0x60 mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common] mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb] __mt76_tx_queue_skb+0x54/0xe8 [mt76] mt76_txq_schedule.part.0+0x204/0x478 [mt76] mt76_txq_schedule_all+0x50/0x80 [mt76] mt792x_tx_worker+0x68/0x100 [mt792x_lib] __mt76_worker_fn+0x84/0x150 [mt76] Müəyyən bir konfiqurasiyanın bu problemə rast gəlməsi, daxil olan netdev-in öz rx skb-lərində nə qədər boşluq saxlamasından asılıdır. Problem, daxili ethernet portunu Netgear A9000 ilə körpüləndirən Raspberry Pi 5-də təkrar istehsal edilmişdir; ilkin olaraq OpenWrt işlədən MT7986 routerində bildirilmişdi. Nick Morrow-nun daha çox boşluq saxlayan Pi 4 (bcmgenet) üzərindəki sınaqları problemin tetikleyicisinin giriş yolu (ingress path) olduğunu müəyyən etməyə kömək etmişdir. Eyni xəta mt7921-də 98c4d0abf5c4 ("mt76: mt7921: don't assume adequate headroom for SDIO headers") komiti ilə düzəldilmişdi, lakin mt7925 kodu mt7921-dən düzəlişsiz şəkildə kopyalanmışdı. Eyni qoruyucu mexanizm bura da əlavə edildi.