CVE-2026-97602 in Linux
Riassunto
di VulDB • 25/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
inet: frags: invalidare le code prima di svuotarle
fqdir_pre_exit() svuota gli skbs dalle code incomplete senza modificarne lo stato di completamento. Un frammento che trova una coda prima che high_thresh sia azzerato può quindi acquisire il lock della coda e riutilizzare metadata di riassemblaggio obsoleti (stale). Una coda uccisa in concorrenza dopo l'impostazione di fqdir->dead può invece diventare INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD mantenendo ancora i suoi vecchi skbs; saltarla perché considerata completa lascia quei riferimenti attivi fino allo smontaggio asincrono della fqdir.
Per IPv6, metadata obsoleti possono far sì che ip6_frag_reasm() utilizzi il vecchio nhoffset con un nuovo skb e acceda alla memoria oltre i limiti (out of bounds). La conseguente corruzione dell'heap può essere sfruttata per l'elevazione locale dei privilegi quando sono disponibili namespace di rete non privilegiati. I frammenti non svuotati possono inoltre mantenere attivi i riferimenti conntrack dopo il punto di pulizia per-net del conntrack.
Uccidere ogni coda incompleta, quindi svuotare tutte le code ancora possedute dalla rhashtable morente. HASH_DEAD identifica tale proprietà; le code complete senza questo flag sono già possedute da un altro percorso di distruzione e devono essere lasciate intatte. Il rilascio del riferimento al timer rimosso da inet_frag_kill() è differito a inet_frag_putn(), dopo il rilascio del lock della coda.
Rapporto KASAN:
BUG: KASAN: slab-out-of-bounds in ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) Write of size 1 at addr ff110001039c6e00 by task poc/771 Call Trace: ? ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479 (discriminator 5)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00)
BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) Read of size 1 at addr ff110001039c6e08 by task poc/771 Call Trace: ? ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) packet_sendmsg (net/packet/af_packet.c:2959 net/packet/af_packet.c:3053 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 8 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.