CVE-2026-98829 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
wifi: mac80211: descartar fragmentos sobredimensionados para evitar un desbordamiento en extra_len
En ieee80211_rx_h_defragment(), las cargas útiles de los fragmentos se acumulan en entry->extra_len a medida que llegan más fragmentos:
entry->extra_len += rx->skb->len;
Cuando llega el último fragmento, el fragmento principal (head) se elimina de la cola y se llama a pskb_expand_head() con entry->extra_len para garantizar un espacio suficiente en la parte final (tailroom) para todos los fragmentos encolados antes de copiarlos:
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); }
En el commit 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry"), entry->extra_len se redujo de unsigned int a u16 con el fin de reducir la huella de memoria de la estructura.
Sin embargo, una secuencia de marcos IEEE 802.11 puede contener hasta 16 fragmentos (números de fragmento del 0 al 15). Si llega una secuencia de fragmentos grandes (por ejemplo, desde un par malicioso o un AP no autorizado), la suma de las longitudes de los fragmentos puede superar los 65.535 bytes (por ejemplo, 15 fragmentos de 4400 bytes suman en total 66.000 bytes). Dado que extra_len es una u16, esta operación provoca un desbordamiento y se envuelve módulo 65536 (por ejemplo, 66.000 se convierte en 464).
Como consecuencia, pskb_expand_head() asigna solo la cantidad truncada de espacio tailroom (o se omite por completo si el fragmento principal ya tiene >= 464 bytes de tailroom). Cuando skb_put_data() itera posteriormente a través de la lista skbs encolados, anexa toda la carga útil al búfer insuficiente, lo que provoca que skb_put() active skb_over_panic() y haga que el kernel falle (crash) en contexto softirq.
Un MSDU legítimo en IEEE 802.11 tiene como máximo 2304 bytes (o hasta 7935/11454 bytes para A-MSDU, que no se fragmenta), muy por debajo de U16_MAX.
Corrija esto sin aumentar el tamaño de la estructura struct ieee80211_fragment_entry verificando si añadir la longitud del fragmento entrante excedería U16_MAX. Si es así, purgue los fragmentos encolados y deseché el marco.
[asignar una razón de descarte separada]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.