CVE-2026-98401 in Linux
Summary
by MITRE • 10/14/2026
In the Linux kernel, the following vulnerability has been resolved:
net: iptunnel: fix stale transport header during tunnel decapsulation
Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale transport_header offset after tunnel decapsulation.
BUG: unable to handle page fault for address: ffffed102091a42e Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__asan_load2 <IRQ> qdisc_pkt_len_segs_init (net/core/dev.c:4145) __dev_queue_xmit (net/core/dev.c:4787) br_dev_queue_push_xmit (net/bridge/br_forward.c:53) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:315) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6099) __netif_receive_skb_list_core (net/core/dev.c:6287) netif_receive_skb_list_internal (net/core/dev.c:6445) napi_complete_done (net/core/dev.c:6813) gro_cell_poll (net/core/gro_cells.c:74) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 ) __local_bh_enable_ip (kernel/softirq.c:450) tun_get_user (drivers/net/tun.c:1986 (discriminator 1)) tun_chr_write_iter (drivers/net/tun.c:2032)
The issue is completely latent until qdisc read transport header in commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()"). The crash requires four conditions to line up:
1. The incoming packet is encapsulated and carries GSO metadata. The outer transport header offset is stored in skb->transport_header while the packet is still in the outer tunnel context. 2. The tunnel receiver strips the outer headers. skb->data is advanced to the inner frame, but skb->transport_header is left pointing to the now-removed outer L4 header, so it becomes a negative offset relative to the new data. 3. The inner frame is not delivered to the local IP stack. Instead, it is forwarded at L2 by a bridge or HSR, so ip_rcv_core() never runs and the transport header is not reset to the inner L4 offset. 4. The forwarding path calls __dev_queue_xmit(), which enters qdisc_pkt_len_segs_init(). That function computes the GSO header length from skb_transport_offset(skb). Because the offset is negative, the unsigned cast overflows and pskb_may_pull(skb, hdr_len + sizeof(struct tcphdr)) reads past the end of the skb, triggering a KASAN fault or page fault.
The issue specifically requires GSO packets (shinfo->gso_size != 0), which are processed/aggregated through gro_cells. Fix this by clearing transport_header to the ~0U sentinel in gro_cell for all tunnnel driver. GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
The Linux kernel contains a critical vulnerability within the network tunneling subsystem that results in a use-after-free condition and subsequent kernel panic due to improper handling of transport header offsets during packet decapsulation. This flaw was identified by Syzbot through automated fuzzing, which triggered a crash in the qdisc_pkt_len_segs_init function located in net/core/dev.c. The root cause lies in the state management of socket buffer metadata when processing encapsulated packets with Generic Segmentation Offload GSO capabilities. When an incoming packet is received as part of an outer tunnel and carries GSO metadata, the kernel stores the offset to the outer layer four transport header within the skb->transport_header field while the packet remains in its original outer context. Upon decapsulation by the tunnel receiver, the driver correctly advances the skb->data pointer to point at the beginning of the inner frame but fails to update or reset the skb->transport_header field. Consequently this offset continues to reference the location of the now-removed outer layer four header relative to the new data base resulting in a negative value that is invalid for the current packet structure.
The severity and exploitability of this vulnerability depend on a specific sequence of operational conditions aligning within the network stack. First, the incoming traffic must be encapsulated and possess GSO metadata indicating it requires segmentation processing later in the pipeline. Second, after decapsulation strips the outer headers leaving only the inner frame, the transport header pointer remains stale pointing to memory outside the current packet bounds. Third, instead of being delivered locally for IP stack processing where functions like ip_rcv_core would typically reset these offsets correctly, the inner frame is forwarded at layer two by a bridge or High Availability Seamless Redundancy HSR implementation. This bypasses the standard local delivery path that would otherwise correct the header pointers. Finally when this malformed packet enters the transmission queue via __dev_queue_xmit it reaches qdisc_pkt_len_segs_init which attempts to compute GSO header lengths using skb_transport_offset. Because the offset is negative casting it to an unsigned integer causes a massive arithmetic overflow leading pskb_may_pull to request reading past the end of the allocated socket buffer memory this triggers either a Kernel Address Sanitizer KASAN fault or a standard page fault resulting in system instability and potential denial of service for affected network interfaces.
This vulnerability maps directly to CWE-125 Out-of-bounds Read as it involves accessing memory beyond the valid bounds of the packet data structure due to incorrect pointer arithmetic derived from stale metadata. From an offensive security perspective aligned with MITRE ATT&CK techniques this flaw facilitates Denial of Service DoS via resource exhaustion or system crash specifically under technique T1499 Endpoint Denial of Service by exploiting kernel-level memory corruption through crafted network traffic. The impact is particularly acute in environments utilizing virtualized networking such as QEMU KVM setups where tun/tap devices are commonly used to inject packets into the guest OS network stack attackers can craft encapsulated GSO packets that trigger this path causing immediate host or guest system crashes depending on which side processes the malformed frames.
Mitigation strategies focus on correcting the state management of header offsets during tunnel decapsulation and restricting problematic packet types in protocols that do not support aggregation features. The primary fix involves modifying gro_cell_poll to explicitly clear the transport_header field setting it to ~0U sentinel value for all tunnel drivers ensuring that any subsequent access attempts fail safely or are handled correctly rather than proceeding with invalid negative offsets specifically targeting GTP tunnels which do not support Generic Receive Offload GRO or GSO should drop packets carrying such metadata directly at ingress preventing them from entering the vulnerable code paths entirely. System administrators running affected kernel versions should apply upstream patches addressing net iptunnel stale transport header issues and verify that network configurations involving bridges HSR and tunneling endpoints are updated to prevent exploitation through crafted encapsulated traffic patterns leveraging GSO features in unsupported protocol contexts.