Look up another CVE · open CVE-2026-99999 in the interactive tracker
CVE-2026-99999
ipv4: validate checksum_start before completing checksum
Published 2026-10-15 (4 days ago) by the Linux kernel CNA. Subsystem include/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-99999 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.11-1 | Update the kernel and reboot. Fixed in 7.2.11-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.11-1 | Update the kernel and reboot. Fixed in 7.2.11-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work.
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.
include/net/ip.h
net/bridge/netfilter/nf_conntrack_bridge.c
net/ipv4/ip_output.c
net/netfilter/nfnetlink_queue.c
net/netfilter/xt_CHECKSUM.c
net/xfrm/xfrm_output.c
- What this is
- NETWORKING [IPv4/IPv6]MAINTAINERS section matched on include/net/ip* · netdev@vger.kernel.org · Maintained
- Kernel module
- nf_conntrack_bridge
Check it on the machine
grep -wE 'CONFIG_BRIDGE|CONFIG_NETFILTER|CONFIG_NF_CONNTRACK_BRIDGE' /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 nf_conntrack_bridgePrints 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_BRIDGE, CONFIG_NETFILTER, CONFIG_NF_CONNTRACK_BRIDGE
- 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-10-15 (4 days ago)source
- CVSS
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.21%, higher than 10.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.27 | 5.10.272 | a464d950f31c |
| 2.6.27 | 5.15.223 | 0fab003ef469 |
| 2.6.27 | 6.1.190 | 94524b7b3269 |
| 2.6.27 | 6.6.159 | a65f69e0f38f |
| 2.6.27 | 6.12.113 | 32a8b0adaa18 |
| 2.6.27 | 6.18.57 | f3e835af6226 |
| 2.6.27 | 7.2.11 | c3e334647461 |
| 2.6.27 | 7.3 | 6785011f8b16 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
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:LAttack vector, local
- A malicious microVM supplies crafted virtio-net checksum metadata with its outbound frame. The VMM writes it to the host TAP, where tun_get_user() feeds the skb to the IPv4 stack and ip_do_fragment() calls skb_checksum_help(); this is a guest/local virtual-device path, not an Internet receive path.
- AC:LAttack complexity, low
- The guest controls the frame, checksum start and offset, and packet size and can repeat the same fragmentation sequence. No race, timing window, or uncontrollable memory layout is needed; host leak, crash, and code-execution variants were reproduced with crafted packets.
- PR:NPrivileges required, none
- In the microVM scenario, a tenant workload able to transmit through its assigned virtio-net interface can supply the triggering traffic. It needs no host credentials, capability, or access to /dev/net/tun; the privileged VMM merely forwards guest output to its existing TAP fd.
- UI:NUser interaction, none
- The attacker sends the crafted guest packets directly, and host TAP/IPv4 processing invokes checksum completion automatically. No host administrator or other victim must act.
- S:CScope, changed
- The checksum metadata originates in an untrusted microVM, but skb_checksum_help() and ip_do_fragment() process and corrupt state in the host kernel. The demonstrated leak, crash, and administrator code execution cross the guest-to-host isolation boundary.
- C:HConfidentiality impact, high
- After skb_checksum_help() changes an already-validated IPv4 IHL, ip_do_fragment() trusts the new length and ip_frag_next() copies beyond the skb's logical linear head into transmitted IPv4 options. This was demonstrated as continuous host-memory disclosure in guest-emitted packets.
- I:HIntegrity impact, high
- skb_checksum_help() writes at the attacker-controlled checksum position inside an IPv4 header after routing and validation, and downstream code trusts the modified fields. Crafted guest packets using this flaw were demonstrated to execute commands with full administrator privileges on the host.
- A:HAvailability impact, high
- Malformed checksum offsets reach skb_checksum_help() from IPv4 fragmentation and can trip WARN_ONCE/panic paths or poison the header geometry used downstream. Crafted guest packets were demonstrated to crash the physical host, taking down all sandboxes on it.