Cloudanix VulnDB

CVE-2026-98401

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the Linux kernel handles certain network tunnel traffic can make systems crash when packets are forwarded through bridges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Stale transport_header offset after tunnel decapsulation on GSO packets forwarded at L2 causes negative offset, leading to out-of-bounds read and page fault or KASAN fault in qdisc_pkt_len_segs_init during __dev_queue_xmit.

Why it matters to the business

Network processing instability or kernel crashes on systems handling tunnel traffic and bridging can result in service outages and require reboots or restarts of affected hosts.

How an attack unfolds

An attacker sends encapsulated GSO packets into a tunnel interface; after decapsulation the stale outer transport header offset remains, the inner frame is L2-forwarded by a bridge without ip_rcv reset, and qdisc processing on the forwarded path triggers the overflow read.

How to fix it

Apply the upstream fix that clears transport_header to the ~0U sentinel inside gro_cell_poll for all tunnel drivers; additionally drop GSO packets directly in GTP. Rebuild and deploy updated kernels to all affected systems.

How to confirm the fix worked

Confirm presence of the clearing logic in gro_cell for tunnel paths and absence of the stale offset path; test with GSO-encapsulated packets forwarded through bridges and verify no oops in qdisc_pkt_len_segs_init.

Typical attack path

  1. Send encapsulated GSO packet targeting a tunnel interface
  2. Trigger decapsulation that advances skb data without resetting transport_header
  3. Ensure L2 forwarding via bridge or HSR bypasses local IP stack delivery
  4. Invoke qdisc_pkt_len_segs_init on the forwarded skb to cause out-of-bounds access

How to detect it

Search kernel logs and crash dumps for oops or page faults referencing qdisc_pkt_len_segs_init, __dev_queue_xmit, br_handle_frame, and tun_get_user during GRO/GSO processing of decapsulated packets.

  • qdisc_pkt_len_segs_init
  • unable to handle page fault for address
  • tun_get_user
  • br_handle_frame_finish
  • pskb_may_pull

What your security team should do

  • Apply kernel updates containing the gro_cell transport_header sentinel fix as soon as available
  • Disable GRO/GSO on tunnel interfaces where operationally feasible until patched
  • Monitor kernel logs for oops involving qdisc_pkt_len_segs_init and tun_get_user

The record

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.

Affected packages

Ecosystem Package Introduced Fixed