Look up another CVE · open CVE-2026-53235 in the interactive tracker
CVE-2026-53235
net: add pskb_may_pull() to skb_gro_receive_list()
Published 2026-06-25 (4 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-53235 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 | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without first ensuring the data is in the linear area via pskb_may_pull(). When the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in page fragments) while skb_gro_offset is non-zero (after IP+TCP header parsing). The skb_pull() then decrements skb->len by skb_gro_offset but skb->data_len stays unchanged, hitting BUG_ON(skb->len < skb->data_len) in __skb_pull(). The UDP fraglist GRO path already contains this guard at udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides centralized protection for all callers (TCP, UDP, and any future protocols), and ensures the precondition of skb_pull() is satisfied before it is called. On pskb_may_pull() failure, set NAPI_GRO_CB(skb)->flush = 1 so the skb is not held as a new GRO head and is instead delivered through the normal receive path, matching the UDP handling.
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/gro.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, sidy
- 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-06-25 (4 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.44%, higher than 36.8% 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.10 | 6.12.94 | 9e636c995b7b |
| 6.10 | 6.18.36 | 0cde3a004119 |
| 6.10 | 7.0.13 | 848571dcbbbe |
| 6.10 | 7.1 | f2bb34345444 |
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 vulnerable GRO path processes received IPv4/IPv6 TCP packets in the network stack before socket authentication or routing decisions. A remote peer can send crafted same-flow packets to an exposed interface with fraglist GRO enabled.
- AC:LAttack complexity, low
- Given a vulnerable deployment with rx-gro-list enabled, the attacker controls the packet stream, header layout, checksums, and sequencing needed to reach skb_gro_receive_list(). No race or victim state outside the attacker’s packet timing is required.
- PR:NPrivileges required, none
- The code runs on unauthenticated packet receive before any application or TCP connection authorization. No local account or kernel capability is required for a remote sender.
- UI:NUser interaction, none
- Exploitation only requires packet delivery to the target network interface. No victim user action is needed.
- S:UScope, unchanged
- The impact is within the kernel/network stack security authority of the targeted system. There is no VM, IOMMU, or sandbox boundary crossing.
- C:NConfidentiality impact, none
- The bug triggers an internal skb length invariant failure in __skb_pull() and immediately BUGs. I found no out-of-bounds read, use-after-free, or usable information disclosure primitive before the crash.
- I:NIntegrity impact, none
- The vulnerable operation corrupts skb metadata only enough to trip the immediate BUG_ON path. It does not provide an attacker-controlled write or persistent data modification primitive.
- A:HAvailability impact, high
- The reachable failure is BUG() in __skb_pull(), causing a kernel oops/panic or loss of system availability. A remote attacker can repeat the packet sequence to repeatedly crash affected deployments.