Look up another CVE · open CVE-2026-74406 in the interactive tracker
CVE-2026-74406
vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74406 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 | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| 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
udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().
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/vxlan/vxlan_core.c
- What this is
- NETWORKING DRIVERSMAINTAINERS section matched on drivers/net/ · netdev@vger.kernel.org · Maintained
- Kernel module
- vxlan
Check it on the machine
grep -w CONFIG_VXLAN /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 vxlanPrints 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_VXLAN
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
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.49%, higher than 40.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 4.7 | 6.1.178 | 9c58c729d32e |
| 4.7 | 6.6.145 | f79c80f173fd |
| 4.7 | 6.12.97 | 08f40c0d23c6 |
| 4.7 | 6.18.40 | 4a8cde6f7281 |
| 4.7 | 7.1.5 | ef44dac2a37f |
| 4.7 | 7.2 | 30a45c0bffdd |
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 vxlan_gro_prepare_receive() on the UDP GRO receive path; remote VXLAN/UDP packets reach it via inet_gro_receive→udp4_gro_receive→udp_tunnel_gro_rcv→vxlan_gro_receive during NAPI processing on internet/cloud overlay endpoints.
- AC:LAttack complexity, low
- An attacker can reliably trigger the race by flooding VXLAN GRO packets while concurrently tearing down the VXLAN device (e.g., via CAP_NET_ADMIN in a user namespace); repeated attempts during orchestrated interface churn also make the timing window attacker-driven rather than purely environmental.
- PR:NPrivileges required, none
- Exploitation requires only the ability to send crafted VXLAN UDP traffic to a listening tunnel port; no target credentials or local account are needed, and concurrent teardown can occur from normal administrative or automation activity rather than attacker-held privileges.
- UI:NUser interaction, none
- No victim interaction is required beyond the host already running a VXLAN interface; the attacker triggers the fault purely by sending network packets timed against interface teardown.
- S:UScope, unchanged
- Impact is a kernel fault in networking softirq context on the same host; it does not cross VM, container, or IOMMU security boundaries into another authority.
- C:HConfidentiality impact, high
- The race can leave a stale vxlan_sock pointer after udp_tunnel_sock_release() frees sk_user_data; dereferencing vs->flags is a use-after-free read that can expose kernel heap contents and is treated as arbitrary read potential under conservative scoring.
- I:HIntegrity impact, high
- Use-after-free on the vxlan_sock object during GRO teardown can corrupt heap metadata or adjacent objects and be leveraged for control-flow hijacking, not merely a benign NULL check failure.
- A:HAvailability impact, high
- A successful trigger causes a kernel NULL pointer dereference/oops in NAPI/softirq context (documented crash at vxlan_gro_prepare_receive), typically crashing or hanging the host and denying all services.