CVE-2026-98829 in Linux
Zusammenfassung
von VulDB • 19.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
wifi: mac80211: Verwerfen von überlangen Fragmenten zur Vermeidung eines extra_len-Überlaufs (Integer Overflow)
In ieee80211_rx_h_defragment() werden die Nutzlastdaten der Fragmente in entry->extra_len angesammelt, während nachfolgende Fragmente eintreffen:
entry->extra_len += rx->skb->len;
Wenn das letzte Fragment eintrifft, wird das Kopf-Fragment aus der Warteschlange entfernt und pskb_expand_head() mit entry->extra_len aufgerufen, um sicherzustellen, dass für alle wartenden Fragmente vor dem Kopieren ausreichend Platz am Ende des Puffers (tailroom) vorhanden ist:
if (skb_tailroom(rx->skb) < entry->extra_len) {
if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len, GFP_ATOMIC))) {
... } } while ((skb = __skb_dequeue(&entry->skb_list))) {
skb_put_data(rx->skb, skb->data, skb->len); dev_kfree_skb(skb); }
Im Commit 69f132236827 („mac80211: shrink struct ieee80211_fragment_entry") wurde entry->extra_len von unsigned int auf u16 reduziert, um den Speicherverbrauch der Struktur zu verringern.
Eine IEEE-802.11-Framesequenz kann jedoch bis zu 16 Fragmente enthalten (Fragmentnummern 0..15). Wenn eine Sequenz großer Fragmente eintrifft (z. B. von einem böswilligen Peer oder einer rogue AP), kann die Summe der Fragmentlängen 65535 Bytes überschreiten (beispielsweise ergeben 15 Fragmente mit je 4400 Bytes insgesamt 66000 Bytes). Da extra_len ein u16 ist, führt dies zu einem Integer Overflow und einer Überlaufumwandlung modulo 65536 (z. B. wird 66000 auf 464 reduziert).
Folglich alloziert pskb_expand_head() nur die abgeschnittene Menge an tailroom oder wird ganz übersprungen, wenn das Kopf-Fragment bereits über >= 464 Bytes an tailroom verfügt. Wenn skb_put_data() anschließend durch die Warteschlange der skbs iteriert, hängt es den vollständigen Payload in den zu kleinen Puffer ein, was dazu führt, dass skb_put() einen skb_over_panic auslöst und den Kernel im softirq-Kontext abstürzt.
Ein legitimes MSDU (MAC Service Data Unit) in IEEE 802.11 ist maximal 2304 Bytes groß (oder bis zu 7935/11454 Bytes für A-MSDU, das nicht fragmentiert wird), was deutlich unter U16_MAX liegt.
Beheben Sie dieses Problem, ohne die Größe der Struktur ieee80211_fragment_entry zu erhöhen, indem Sie prüfen, ob das Hinzufügen der Länge des eingehenden Fragments U16_MAX überschreiten würde. Wenn ja, löschen Sie die wartenden Fragmente und verwerfen den Frame.
[weisen Sie eine separate Verwerfungsursache (drop reason) zu]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.