CVE-2026-53175: inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush
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.
Security readout for executives and security teams
Plain-English summary
A race during Linux network-namespace shutdown can leave the kernel using already-freed network-fragment data. A network fragment arriving at the wrong moment may trigger memory corruption, potentially affecting confidentiality, integrity, or availability. The source bundle rates this critical, but does not establish real-world exploitation.
Executive priority
Treat as an urgent kernel remediation item because the documented flaw is remotely reachable and memory-corrupting. First validate vendor-specific exposure, then patch internet-facing and container-intensive Linux systems promptly. There is no source-backed evidence of active exploitation, so incident response should be driven by telemetry rather than assumed compromise.
Technical view
fqdir_pre_exit() flushes incomplete fragment queues without marking them complete or clearing three pointers. A fragment that previously obtained the queue can resume and dereference freed skb memory, causing a slab use-after-free. IPv6, nf_conntrack_reasm6, and 6LoWPAN share the affected path. The fix clears the stale queue pointers after flushing.
Likely exposure
Potential exposure exists on systems using the bundle-listed affected Linux versions, particularly where fragment reassembly can overlap network-namespace teardown. The bundle lists 6.19, 6.12.94, 6.18.36, 7.0.13, and 7.1 as affected, but its version data requires vendor confirmation before making fleet-wide conclusions.
Exploitation context
The CVSS 3.1 vector reports network reachability, low complexity, no privileges, and no user interaction. However, exploitation requires a timing condition involving fragment processing and network-namespace teardown. The bundle marks KEV false and supplies no evidence of active exploitation or a public exploit.
Researcher notes
The vulnerable window exists because lowering high_thresh blocks new lookups but not a fragment already holding the queue reference. The flush frees queued skbs while leaving rb_fragments, fragments_tail, and last_run_head stale. Clearing those fields makes a resumed fragment encounter an empty queue. Exact branch and distribution applicability should be verified against the linked commits and vendor data.
Mitigation direction
Apply a vendor-approved kernel update containing the applicable stable fix.
Prioritize exposed systems that process untrusted fragmented traffic or frequently tear down network namespaces.
If updates are unavailable, request vendor-supported mitigations; none are confirmed in the bundle.
Restart into the updated kernel following normal change-control procedures.
Validation and detection
Inventory running kernel versions and compare them with the vendor advisory and bundle status.
Confirm the installed kernel contains the applicable stable fix commit or vendor backport.
After updating, verify systems are running the intended patched kernel.
Review kernel crash and memory-corruption telemetry, recognizing that such events do not prove exploitation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-825: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
1ADP providers
9Source links
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.