Look up another CVE · open CVE-2026-72319 in the interactive tracker
CVE-2026-72319
ipvs: ensure inner headers in ICMP errors are in headroom
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem net/netfilter. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72319 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
Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.
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.
net/netfilter/ipvs/ip_vs_core.c
- What this is
- IPVSMAINTAINERS section matched on net/netfilter/ipvs/ · netdev@vger.kernel.org · Maintained
- Kernel module
- ip_vs
Check it on the machine
grep -wE 'CONFIG_IP_VS|CONFIG_NETFILTER' /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 ip_vsPrints 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 switches
- CONFIG_IP_VS, CONFIG_NETFILTER
- Reads as
- all on means the file is compiled; any one off means it is not.
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.76%, higher than 54.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/netfilter
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.7 | 5.10.261 | 19657b3a17b7 |
| 3.7 | 5.15.212 | dac813101914 |
| 3.7 | 6.1.178 | dd22f74a09e2 |
| 3.7 | 6.6.145 | 9bc9b95aee2b |
| 3.7 | 6.12.97 | a735f9964a3d |
| 3.7 | 6.18.40 | 8f48cfe65740 |
| 3.7 | 7.1.5 | 92185d6f7819 |
| 3.7 | 7.2 | 3f7a535ff0fa |
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
- Crafted IPv4 ICMP error packets reach ip_vs_in_icmp() through IPVS netfilter LOCAL_IN and FORWARD hooks on internet-facing load balancers and Kubernetes kube-proxy IPVS nodes; remote senders trigger the tunnel PMTUD handler without local access.
- AC:LAttack complexity, low
- An attacker controls ICMP nesting, IPIP/UDP/GRE encapsulation, skb fragmentation/non-linear layout, and can establish matching IPVS TUN connections through the VIP; no race or condition outside attacker control is required once IPVS tunnel mode is deployed.
- PR:NPrivileges required, none
- IPVS configuration is an administrator deployment prerequisite; a remote attacker sending ICMP errors to an already-configured load balancer needs no credentials or host capabilities on the victim.
- UI:NUser interaction, none
- Exploitation is driven entirely by network packets processed automatically in softirq; no victim user action beyond normal traffic through the load balancer is required.
- S:UScope, unchanged
- Out-of-bounds kernel skb header access and route PMTU corruption remain within the host kernel authority; this is standard kernel compromise, not VM escape or sandbox crossing.
- C:HConfidentiality impact, high
- After pskb_pull() without pskb_may_pull(), ipv4_update_pmtu() and ip_hdr() dereference skb->data that may lie past skb_tail_pointer or hold non-linear fragment data, constituting an out-of-bounds kernel read per CNA guidance.
- I:HIntegrity impact, high
- Mis-parsed inner IP header fields from unchecked skb->data drive ipv4_update_pmtu() route lookups and FNHE/PMTU updates with attacker-influenced saddr/daddr values, enabling unauthorized modification of kernel routing state.
- A:HAvailability impact, high
- Out-of-bounds header access in the IPVS ICMP tunnel path can trigger kernel oops or panic, and a remote attacker can repeatedly send crafted ICMP errors to deny service on IPVS TUN load balancers.