No kernel Linux, a seguinte vulnerabilidade foi resolvida. inet: frags: tira o estado do GSO de fragmentos antes da reassemblagem Um virtio_net_hdr (tun/tap, ou AF_PACKET com PACKET_VNET_HDR) pode marcar um IPv 4 ou IPv 6 fragmento 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 a cabeça do datagrama reassemblado, incluindo o seu shinfo->gso_size/gso_type/gso_segs, e encadeia os fragmentos restantes na frag_list com qualquer layout linear/ de página que eles tenham chegado.
Após ip_defrag() (ip_local_delivery(), nf_defrag_ipv 4,...) o skb reassembléiado, portanto, ainda afirma ser GSO (SKB_GSO_DODGY), e o próximo ponto de segmentação de software - udp_rcv_segment() na entrega local, validar_xmit_skb(), ou o caminho lento ip_finish_output_gso() - entrega- o ao skb_segment(). o caminhada frag_list do skb_segment() assume entrada em forma de GRO e atinge um dos seus BUG_ON()s. Dois gravados a uma torneira por um usuário desprivilegiado em seus próprios usuários são suficientes: BUG do kernel na rede/core/skbuff.c: 4899! Oops: opcode inválido: 0000 [# 1 ] CPU KASAN NOPTI SMP: 0 UID: 1000 PID: 82 Comunicação: poc Não manchado 7.2.0 - mais pendente+ # 2 RIP: 0010:skb_segment+ 0 x 20 ca/ 0 x 48 b 0 Chame o rastreamento: __udp_gso_segment+ 0 x 29 a/ 0 x 27 d 0 udp 4 _ufo_fragment+ 0 x 458 / 0 x 6 c 0 inet_gso_segment+ 0 x 429 / 0 x 1340 skb_mac_gso_segment+ 0 x 233 / 0 x 4 f 0 __skb_gso_segment+ 0 x 308 / 0 x 660 udp_queue_rcv_skb+ 0 x 440 / 0 xad 0 udp_unicast_rcv_skb+ 0 xc 7 / 0 x 2 c 0 udp_rcv+ 0 x 16 ce/ 0 x 2260 ip_protocol_deliver_rcu+ 0 x 197 / 0 x 2 d 0 ip_local_deliver+ 0 x 430 / 0 x 690 ip_rcv+ 0 x 16 f/ 0 x 1 f 0 __netif_receive_skb_one_core+ 0 x 15 e/ 0 x 1 c 0 __netif_receive_skb+ 0 x 1 e/ 0 x 110 netif_receive_skb+ 0 xf 6 / 0 x 5 c 0 Tun_rx_batched. isra. 0 + 0 x 3 Ab/ 0 x 790 tun_get_user+ 0 x 17 c 3 / 0 x 3550 tun_chr_write_iter+ 0 xba/ 0 x 1 b 0 vfs_write+ 0 x 646 / 0 x 1130 Pânico no núcleo - não sincronização: exceção fatal na interrupção.
Isto funciona com BH desativado, por isso é um pânico em vez de um oops. O mesmo é alcançável com CAP_ NET_ RAW em uma rede onde um ponto de defragagem precede um ponto GSO, e de um convidado cujo VMM encaminha virtio_ NET_ hdr para uma torneira. As verificações da SKB_GSO_DODGY frag_list adicionadas por commit 3 dcbdb 134 f 32 ("net: gso: corrigir o skb_segment splat ao dividir o gso_size skb mangled tendo a frag_list com cabeça linear") e por commit 9 e 4 b 7 a 99 a 03 a ("net: gso: corrigir o pânico na frag_list com tipos mistos de allocs de cabeça") não cobre: cabeças de página- apoiadas os ignoram, e cabeças de kmalloc os ignoram quando gso_size == skb_headlen(head), que o remetente controla. Um skb que insere uma fila de frag é um fragmento IP por definição e não pode carregar o estado GSO legitimamente: o GRO não funde fragmentos e os segmentos da pilha antes deles fragmentados, por isso só fontes não confiadas são afetadas. Isto tem sido alcançável desde que se compromete f 43798 c 27684 ("tun: Permitir GSO usando virtio_net_hdr"), o primeiro caminho que permite que o espaço de usuário acople metadados GSO a um fragmento de IP. Reinitirar os campos GSO de cada fragmento conforme for colado, em inet_frag_queue_insert(), que IPv 4, IPv 6, nf_conntrack_reasm e 6 compartilhar a reassembléia de lowpan; então nem os membros da cabeça nem os membros da lista de frag_list do skb reassemblém os carregam (os membros também importam: o ip_do_fragment()/ip 6 _fragment() caminhos rápidos os enviam como estão. A cabeça pode permanecer CHECKSUM_PARTIAL; isso já é aceito ao receber e resolver pelo skb_checksum_help() no ip_do_fragment()/ip 6 _fragment() no percurso.
Testado em cima do net.git (dc 4 b 95 b 8 taxa 9 ), x 86 _ 64: o reprodutor de toque acima, dois IPv adicionais 4 geometrias frag_list que chegam a BUG_ON(i >= nfrags) e BUG_ON(!list_skb->head_frag), e um IPv 6 variante de cabeçalho de fragmento (udp 6 _ufo_fragment()) cada pânico do kernel não empaquetado; com este patch, todos os quatro datagramas são entregues intactos e nada está registrado.
Registro de aconselhamento: GHSA- m 48 g- 6 cv 9 - p 3 - Não, não, não, não, não, não, não, não, não, não. Identificadores relacionados: CVE- 2026 - 80590.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 28 T 09: 31: 45.000 Z e lista a sua última modificação como 2026 - 08 - 31 T 09: 30: 26.000 Z.
Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H.
Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões.
Classificação e evidência: nenhum identificador CWE está listado. O registro contém 10 suporte de referências nestes tipos: AVISO, WEB.