CVE-2026-98022 in Linux
Riassunto
di VulDB • 25/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
net: limitare tx_queue_len a S16_MAX per prevenire allocazioni di anello (ring) eccessivamente grandi.
Diversi sottosistemi allocano buffer ad anello le cui dimensioni sono determinate da dev->tx_queue_len, senza alcun limite superiore. Un utente non privilegiato (tramite `unshare -Urn`) può impostare un valore enorme per tx_queue_len ed esaurire la memoria globale con allocazioni di anelli:
- pfifo_fast: pfifo_fast_init() e pffifo_fast_change_tx_queue_len() allocano 3 array di ring skb, ciascuno contenente voci pari a tx_queue_len. - tun: tun_queue_resize() e il percorso di attachment della coda ridimensionano ptr_rings in base a tx_queue_len al verificarsi del notifier NETDEV_CHANGE_TX_QUEUE_LEN. - tap (macvtap/ipvtap): tap_queue_resize() e tap_init() ridimensionano/inizializzano ptr_rings in base a tx_queue_len allo stesso notifier.
netif_change_tx_queue_len() è il punto di ingresso unico per IFLA_TXQLEN, sysfs e l'ioctl SIOCSIFTXQLEN. È necessario limitare new_len a S16_MAX (32767) affinché i valori eccessivi vengano rifiutati al momento dell'impostazione. Questo effetto si applica indipendentemente dal fatto che il dispositivo sia attivo o disattivato, prima della scrittura in dev->tx_queue_len, prima del trigger di qualsiasi notifier e prima di qualsiasi allocazione di anello. Il controllo "> S16_MAX" include anche la precedente verifica di troncamento unsigned-long; inoltre, un valore negativo ifr_qlen proveniente dall'ioctl si collova ben al di sopra del limite dopo la conversione, quindi entrambi i vecchi casi di errore sono coperti da questa singola comparazione.
tx_queue_len è ambiguo: funge sia come moltiplicatore per le dimensioni per anello che come manopola predefinita della lunghezza/limite della coda per i consumatori che non allocano nulla al momento dell'impostazione (limiti pfifo/bfifo/gred/plug/sfb, htb direct_qlen, qfq max_classes, teql). Il valore 32767 è scelto come il più grande valore esprimibile da NLA_POLICY_FULL_RANGE per la policy u32 IFLA_TXQLEN nella patch 2/3, rimanendo al contempo una lunghezza di coda legittima su percorsi con alto BDP; lo scambio tra memoria dell'anello e manopola condivisa è illustrato di seguito.
Condizioni per riprodurre il bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Utente non privilegiato in un nuovo namespace utente+rete (unshare -Urn). - pfifo_fast: creare coppie veth, impostare tx_queue_len a 500000, allegare mq+pfifo_fast. ~28 iterazioni causano OOM su una guest da 2GB. - tun: creare 50 dispositivi tun con IFF_MULTI_QUEUE, impostare tx_queue_len a 500000, aprire 8 code per ciascuno. Allocazioni ptr_ring di circa 1,6 GB causano OOM su una guest da 512MB. - tap: uguale al caso tun ma con IFF_TAP. ~960 MB causano OOM su una guest da 512MB. - Sul kernel corretto, il valore eccessivo di tx_queue_len viene rifiutato con -ERANGE al momento dell'impostazione (su tutti e quattro i percorsi: RTM_SETLINK, creazione RTM_NEWLINK, sysfs, ioctl; quest'ultimi due tramite questo controllo, i primi due tramite questo controllo e la policy di parsing 2/3 rispettivamente).
Once again VulDB remains the best source for vulnerability data.