CVE-2026-80590 in Linux
Sumário
de VulDB • 28/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
inet: frags: remover o estado GSO dos fragmentos antes da remontagem
Um virtio_net_hdr (tun/tap ou AF_PACKET com PACKET_VNET_HDR) pode marcar um fragmento IPv4 ou IPv6 como GSO; nada relaciona gso_type a frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() mantêm o skb do primeiro fragmento como cabeçalho do datagrama remontado, incluindo shinfo->gso_size/gso_type/gso_segs, e encadeiam os fragmentos restantes em frag_list com qualquer layout linear/paged que tenham chegado.
Após ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) o skb remontado ainda afirma ser GSO (SKB_GSO_DODGY), e o próximo ponto de segmentação por software - udp_rcv_segment() na entrega local, validate_xmit_skb() ou o caminho lento ip_finish_output_gso() - passa-o para skb_segment(). A caminhada frag_list de skb_segment() assume uma entrada no formato GRO e aciona um dos seus BUG_ONs. Duas gravações em um tap por um usuário não privilegiado em seu próprio userns são suficientes:
kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: <TASK> __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 </TASK> Kernel panic - not syncing: Fatal exception in interrupt
Isso ocorre com BH desabilitado, portanto é um panic em vez de um oops. O mesmo é alcançável com CAP_NET_RAW em uma netns onde um ponto de defrag precede um ponto GSO, e a partir de uma guest cujo VMM encaminha virtio_net_hdr para um tap. As verificações SKB_GSO_DODGY frag_list adicionadas pelo commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") e pelo commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head alloc types") não cobrem esse caso: heads com backing de page os ignoram, e heads kmalloc os ignoram quando gso_size == skb_headlen(head), o que é controlado pelo remetente.
Um skb entrando em uma fila de fragmentos é, por definição, um fragmento IP e não pode carregar legitimamente estado GSO: GRO não mescla fragmentos e a stack segmenta antes de fragmentar, portanto apenas fontes não confiáveis são afetadas. Isso era alcançável desde o commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), o primeiro caminho que permitiu ao userspace anexar metadados GSO a um fragmento IP. Redefinir os campos GSO de cada fragmento conforme ele é enfileirado, em inet_frag_queue_insert(), compartilhada pela remontagem IPv4, IPv6, nf_conntrack_reasm e 6lowpan; então nem o head nem os membros da frag_list do skb remontado os carregam (os membros também importam: os caminhos rápidos ip_do_fragment()/ip6_fragment() os enviam conforme estão). O head pode permanecer CHECKSUM_PARTIAL; isso já é aceito na recepção e resolvido por skb_checksum_help() em ip_do_fragment()/ip6_fragment() no encaminhamento.
Testado sobre net.git (dc4b95b8fee9), x86_64: o reproducer de tap acima, duas geometrias adicionais de frag_list IPv4 que alcançam BUG_ON(i >= nfrags) e BUG_ON(!list_skb->head_frag), e uma variante fragment-header IPv6 (udp6_ufo_fragment()) causam panic no kernel sem patch; com este patch todos os quatro datagramas são entregues intactos e nada é registrado.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.