CVE-2026-80934
NieznaneStreszczenie
W jądrze Linux sterowniki mt7996/mt7992 przekazują firmware'owi HW MAC-TXP dla ramek AddBA req, ale są urządzeniami FW-TXP. Przy zwalnianiu TX funkcja mt76_connac_txp_skb_unmap() błędnie dekoduje txp jako strukturę mt76_connac_fw_txp, przez co pętla unmap wykonuje się zero razy i mapowanie DMA skb w buf[1] nigdy nie jest zwalniane. Każda ramka AddBA req powoduje wyciek jednego mapowania TX DMA, co przy ciągłym ponownym łączeniu klientów wyczerpuje pulę swiotlb WED po około 1-2 dniach.
Ocena ryzyka
Wyciek mapowań DMA prowadzi do wyczerpania puli swiotlb WED, po czym mapowanie DMA zawodzi dla WED, MCU WiFi i innych konsumentów na SoC, powodując awarie sieci bezprzewodowej. Atakujący może wywołać ten stan poprzez ciągłe ponowne łączenie klientów.
Rekomendacja
Zaktualizuj jądro Linux do wersji z poprawką dodającą specyficzne dla mt7996 odmapowanie txp, które sprawdza MT_TXD7_MAC_TXD i zwalnia buf[1] dla ramek MAC-TXP.
Inne podatności w Linux kernel (mt76 mt7996 driver)
Zobacz wszystkie- CVE-2026-80935Nieznane
W jądrze Linux w funkcji mt7996_mcu_get_eeprom() sterownika wifi mt76 (układ mt7996) adres docelowy kopii bloku EFUSE/EXT jest wyliczany na podstawie adresu raportowanego przez MCU (event->addr), a ograniczana jest jedynie długość kopii, nigdy przesunięcie docelowe w buforze eeprom.data. Złośliwe lub wadliwe urządzenie może zgłosić dowolny adres i wymusić zapis poza zakresem bufora eeprom.data o rozmiarze do MT7996_EXT_EEPROM_BLOCK_SIZE bajtów.
- CVE-2026-80933Nieznane
W jądrze Linux domyślny firmware EEPROM jest parsowany i kopiowany jako pełny EEPROM bez sprawdzenia jego długości. Obcięty plik może spowodować odczyt poza buforem firmware podczas walidacji wariantu lub kopii zapasowej.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames mt7996/mt7992 hand the firmware a HW MAC-TXP for AddBA req action frames (MT_TXD7_MAC_TXD, set in mt7996_mac_write_txwi_80211()), but are otherwise FW-TXP devices. On tx free mt76_connac_txp_skb_unmap() therefore decodes the per-frame txp as a struct mt76_connac_fw_txp. For a MAC-TXP the fw_txp.nbuf byte aliases the AddBA TID word (MT_TXP1_TID_ADDBA), which is always zero, so the unmap loop runs zero times and the skb DMA mapping in buf[1] is never unmapped. buf[1].skip_unmap is set unconditionally, so the generic DMA-ring cleanup skips it as well. Each AddBA req therefore leaks one TX DMA mapping, roughly one per (re)association. With WED enabled these mappings are bounced through the WED swiotlb pool, so under continuous client reconnect churn the pool is exhausted after ~1-2 days, after which DMA mapping fails for WED, the WiFi MCU and other on-SoC consumers. Keep the deferred (token release) unmap that the design relies on, and add an mt7996-specific txp unmap that inspects MT_TXD7_MAC_TXD and unmaps buf[1] from the MAC-TXP layout for those frames, delegating to mt76_connac_txp_skb_unmap() otherwise.

