Look up another CVE · open CVE-2026-53175 in the interactive tracker
CVE-2026-53175
inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem net/ipv4. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53175 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 | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| 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
On netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inet_frag_queue_flush(). That helper frees all the skbs queued on the fragment queue but does not set INET_FRAG_COMPLETE, and leaves q->fragments_tail and q->last_run_head pointing at the freed skbs. The queue itself stays in the rhashtable. fqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inet_frag_find() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INET_FRAG_COMPLETE check and then dereferences the freed fragments_tail. inet_frag_queue_insert() reads FRAG_CB() and ->len of that pointer and, on the append path, writes ->next_frag, causing a slab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly share the same flush path and are affected as well. Reset rb_fragments, fragments_tail and last_run_head in inet_frag_queue_flush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragments_tail. ip_frag_reinit() already performed this reset after its own flush, so drop the now duplicate code there.
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/ipv4/inet_fragment.c
net/ipv4/ip_fragment.c
- What this is
- NETWORKING [IPv4/IPv6]MAINTAINERS section matched on net/ipv4/inet_fragment.c · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_INET /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.
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
- Build switch
- CONFIG_INET
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-06-25 (4 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.31%, higher than 22.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/ipv4
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.6.143 | 6.6.143 | 0e823ca0e739 |
| 6.12.93 | 6.12.94 | c22599cc90e1 |
| 6.18.3 | 6.18.36 | 89b909e97045 |
| 6.19 | 7.0.13 | 010c3313a4d1 |
| 6.19 | 7.1 | 32594b098549 |
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
- IPv4 and IPv6 fragment reassembly is reached by received network packets before transport-layer delivery, and the affected generic inet fragment code is shared by network-facing reassembly paths. A remote peer can supply the crafted fragmented traffic that reaches `inet_frag_queue_insert()`.
- AC:LAttack complexity, low
- The vulnerable window is a race between a fragment that already found the queue and netns teardown flushing that queue. The race can be retried and, in attacker-controlled namespace/container scenarios, both fragmented traffic and namespace teardown/churn are attacker-controlled.
- PR:NPrivileges required, none
- No authentication or capability check gates normal IPv4/IPv6 fragment receive and reassembly before the vulnerable queue insertion path. The packet-processing side is reachable pre-authentication by crafted fragmented traffic.
- UI:NUser interaction, none
- Exploitation does not require a victim user to open a file, mount anything, or perform another interactive action. Packet delivery and namespace teardown are kernel/system events.
- S:UScope, unchanged
- The corruption occurs inside the kernel network stack and impacts the same kernel security authority. This is not a guest-to-host, IOMMU, or other explicit security-scope crossing.
- C:HConfidentiality impact, high
- The bug is a slab use-after-free involving freed `sk_buff` objects and stale queue pointers. Such memory corruption can be shaped into kernel memory disclosure primitives.
- I:HIntegrity impact, high
- The append path can write through the stale freed `fragments_tail` object via `next_frag`, producing kernel heap memory corruption. A UAF write primitive is sufficient to support control-flow hijack or arbitrary kernel data modification.
- A:HAvailability impact, high
- Even without full exploitation, dereferencing and writing through freed skb memory can crash or oops the kernel. The fragment path can be triggered repeatedly with crafted traffic.