Look up another CVE · open CVE-2026-74665 in the interactive tracker
CVE-2026-74665
net: fix skb length accounting after generic XDP frag adjustment
Published 2026-08-22 (2 months ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-74665 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 | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Generic XDP exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, bpf_prog_run_generic_xdp() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly.
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/core/dev.c
- What this is
- NETWORKING [GENERAL]MAINTAINERS section matched on net/ · netdev@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
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 Debian linux-config packages
Signals
- Published
- 2026-08-22 (2 months ago)source
- CVSS
- 9.1 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Nsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.37%, higher than 29.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.9 | 6.12.104 | 72468efcc089 |
| 6.9 | 6.18.45 | 5f30f9c302ce |
| 6.9 | 7.1.9 | ea1ccd6d1c63 |
| 6.9 | 7.2 | 33f2b2eb33d6 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-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:NAttack vector, network
- The flaw is hit when remotely delivered packets traverse __netif_receive_skb_core(), netif_receive_generic_xdp(), and bpf_prog_run_generic_xdp() on any netdev with generic XDP (SKB mode) attached, matching the reproduced UDP receive path on a veth pair.
- AC:LAttack complexity, low
- An attacker can reliably send large fragmented datagrams (reproducer used a 60000-byte UDP payload) to create a nonlinear skb and drive bpf_xdp_adjust_tail() fragment shrink before XDP_PASS, with no race or conditions outside attacker packet control.
- PR:NPrivileges required, none
- Exploitation only requires generic XDP using bpf_xdp_adjust_tail to already be attached on a reachable interface; the remote packet sender needs no local account, capabilities, or authentication to trigger the bad skb length accounting.
- UI:NUser interaction, none
- No victim interaction is needed beyond normal always-on packet reception and socket delivery; corrupted/leaked data is produced automatically when a userspace process reads the affected datagram.
- S:UScope, unchanged
- Impact stays within the same kernel/host security authority by leaking kernel memory into a local userspace receive buffer and does not by itself cross VM, container, or IOMMU isolation boundaries.
- C:HConfidentiality impact, high
- Inflated skb_headlen() makes __skb_datagram_iter() copy up to 1024 bytes past the real linear tail into userspace, exposing skb_shared_info metadata and a kernel pointer from skb_shinfo(skb)->frags[0].
- I:HIntegrity impact, high
- The same length mismatch displaces and truncates real packet bytes in the delivered datagram, corrupting application-visible data beyond intended bounds and compounding misuse of leaked kernel metadata.
- A:NAvailability impact, none
- The demonstrated failure is out-of-bounds kernel-to-userspace copy and datagram corruption without a reported kernel panic, oops, hang, or other availability loss in the fix commit or reproduction.