In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: 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 This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") and by commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.

The remote Debian 13 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6477 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6477-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     August 29, 2026                       https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : linux     CVE ID         : CVE-2025-40074 CVE-2026-64216 CVE-2026-64581 CVE-2026-74626                      CVE-2026-74653 CVE-2026-74662 CVE-2026-80536 CVE-2026-80557                      CVE-2026-80562 CVE-2026-80572 CVE-2026-80583 CVE-2026-80590                      CVE-2026-80725

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For the stable distribution (trixie), these problems have been fixed in     version 6.12.107-1.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with     PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.
    inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the     reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments     on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(),     nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next     software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the     ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-     shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns     are enough: 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 This runs with BH disabled, so it is a panic rather than an oops.
    The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a     guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit     3dcbdb134f32 (net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed     frag_list) and by commit 9e4b7a99a03a (net: gso: fix panic on frag_list with mixed head alloc types) do     not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head),     which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot     legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so     only untrusted sources are affected. This has been reachable since commit f43798c27684 (tun: Allow GSO     using virtio_net_hdr), the first path that let userspace attach GSO metadata to an IP fragment. Reset the     GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6,     nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the     reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send     them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and     resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git     (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach     BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant     (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered     intact and nothing is logged. (CVE-2026-80590)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
341563	Debian dsa-6477 : ata-modules-6.12.101+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	critical
341290	Linux Distros Unpatched Vulnerability : CVE-2026-80590	Nessus	Misc.	Local	critical

Detections

Analytics

CVE-2026-80590

high

Tenable Plugins

critical

critical