Look up another CVE · open CVE-2026-72407 in the interactive tracker

CVE-2026-72407

geneve: validate inner network offset in geneve_gro_complete()

10.0 EPSS 0.6% AV:N

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-72407 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.5-1	Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

Even with both paths gated on gs->gro_hint, geneve_gro_complete() re-derives the inner dispatch type and length from the packet and the current gs->gro_hint, independently of geneve_gro_receive(). The two can disagree if gs->gro_hint flips under a concurrent geneve_quiesce()/ geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if the re-read option bytes differ from the ones receive parsed. geneve_gro_receive() already records the inner network header position in NAPI_GRO_CB()->inner_network_offset. Have geneve_gro_complete() compute the offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case where eth_gro_complete() steps over the inner MAC header, and bail out if it lands past inner_network_offset. Use a lower bound rather than exact equality: between gh_len and the inner L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag (vlan_gro_receive() advances the recorded offset past it), which only moves inner_network_offset further out. A valid frame therefore always satisfies inner_nh <= inner_network_offset, while a gh_len inflated by a hint gro_receive() did not honour dispatches past the validated inner header, i.e. the out-of-bounds completion. Only the latter is rejected.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/geneve.c

What this is: NETWORKING DRIVERSMAINTAINERS section matched on drivers/net/ · netdev@vger.kernel.org · Maintained
Kernel module: geneve

Check it on the machine

grep -w CONFIG_GENEVE /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w geneve

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sidm

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switch: CONFIG_GENEVE

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-15 (2 months ago)source
CVSS: 10.0 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.55%, higher than 45.0% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
7.0	7.1.5	e2087447f562
7.0	7.2	cbb0d30a1ad6

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: The bug is in geneve_gro_complete() on the NAPI GRO receive path for UDP-encapsulated GENEVE frames; a remote peer can deliver crafted packets to a listening GENEVE UDP port on cloud/overlay hosts without local access.
AC:LAttack complexity, low: An attacker can reliably trigger the mismatch by flooding GRO-eligible GENEVE frames with crafted GRO-hint options and timing them against geneve_quiesce()/geneve_unquiesce() during changelink, or self-trigger that race with CAP_NET_ADMIN in a user namespace.
PR:NPrivileges required, none: Exploitation requires no credentials or capabilities on the victim; the attacker only needs network reachability to a host already running a gro_hint-enabled GENEVE tunnel, which is common on overlay networks.
UI:NUser interaction, none: Exploitation is fully automated through malicious network traffic and does not require any victim user action such as mounting filesystems or opening files.
S:CScope, changed: On cloud/overlay deployments a tenant VM or remote overlay peer can corrupt the hypervisor/host kernel through underlay GENEVE GRO processing, crossing the guest/host security boundary.
C:HConfidentiality impact, high: When gro_complete() dispatches past inner_network_offset, eth_gro_complete() and inet_gro_complete() read headers from attacker-influenced out-of-bounds skb memory, enabling arbitrary kernel memory disclosure.
I:HIntegrity impact, high: The same out-of-bounds gro_complete dispatch writes header fields (e.g., iph->tot_len and iph->check in inet_gro_complete()), causing memory corruption that can be leveraged for arbitrary write or code execution.
A:HAvailability impact, high: Out-of-bounds GRO completion can cause kernel oops/panic or forced skb drop under error paths, enabling repeatable remote denial of service against the host.