CVE-2026-98022 in Linux
Sumário
de VulDB • 25/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net: limitar tx_queue_len em S16_MAX para evitar alocações de anel excessivamente grandes
Vários subsistemas alocam buffers de anel dimensionados por dev->tx_queue_len sem um limite superior. Um usuário não privilegiado (via unshare -Urn) pode definir um valor enorme para tx_queue_len e esgotar a memória global com alocações de anel:
- pfifo_fast: pfifo_fast_init() e pfifo_fast_change_tx_queue_len() alocam 3 rings de array skb com entradas iguais a tx_queue_len cada. - tun: tun_queue_resize() e o caminho de attachment da fila redimensionam ptr_rings para tx_queue_len no notificador NETDEV_CHANGE_TX_QUEUE_LEN. - tap (macvtap/ipvtap): tap_queue_resize() e tap_init() redimensionam/inicializam ptr_rings para tx_queue_len no mesmo notificador.
netif_change_tx_queue_len() é o único ponto de entrada para IFLA_TXQLEN, sysfs e ioctl SIOCSIFTXQLEN. Limite new_len em S16_MAX (32767) aqui para que o valor excessivamente grande seja rejeitado no momento da configuração. Isso entra em vigor independentemente do dispositivo estar ativo ou inativo, antes de dev->tx_queue_len ser gravado, antes que qualquer notificador dispare e antes que qualquer anel seja alocado. A verificação "> S16_MAX" também abrange o teste anterior de truncamento unsigned-long, e um ifr_qlen negativo do ioctl fica muito acima da limitação após a conversão, portanto, ambos os modos antigos de falha são cobertos por uma única comparação.
tx_queue_len é ambíguo: atua tanto como multiplicador de dimensionamento per-ring quanto como controle padrão de comprimento/limite da fila para consumidores que não alocam nada no momento da configuração (limites pfifo/bfifo/gred/plug/sfb, htb direct_qlen, qfq max_classes, teql). 32767 é escolhido como o maior valor que NLA_POLICY_FULL_RANGE pode expressar para a política u32 IFLA_TXQLEN no patch 2/3, mantendo-se um comprimento de fila legítimo em caminhos com alto BDP; a compensação entre memória do anel e controle compartilhado é detalhada abaixo.
Condições para reproduzir o bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Usuário não privilegiado em um namespace de usuário+rede novo (unshare -Urn). - pfifo_fast: criar pares veth, definir tx_queue_len para 500000, anexar mq+pfifo_fast. ~28 iterações causam OOM em uma VM com 2GB. - tun: criar 50 dispositivos tun com IFF_MULTI_QUEUE, definir tx_queue_len para 500000, abrir 8 filas cada. Alocações de ptr_ring de ~1.6GB causam OOM em uma VM com 512MB. - tap: igual ao tun com IFF_TAP. ~960MB causam OOM em uma VM com 512MB. - No kernel corrigido, o tx_queue_len excessivamente grande é rejeitado com -ERANGE no momento da configuração (todos os quatro caminhos: RTM_SETLINK, criação de RTM_NEWLINK, sysfs, ioctl; estes dois últimos via esta verificação, aqueles dois primeiros via esta verificação e a política de parse 2/3 respectivamente).
If you want to get best quality of vulnerability data, you may have to visit VulDB.