CVE WatchAug 14, 2026

CVE-2026-53175

In the Linux kernel, the following vulnerability has been resolved: inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush O

CVSS

9.8

Critical

EPSS

0.3%

p24

KEV

—

Exploit Today

0-100

Published: Jun 25, 2026 · Last modified: Aug 14, 2026 · CWE-416 · CWE-825

EPSS · 30d

0.3%EPSS · 30 days0.3%

2026-08-142026-09-10

Technical 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.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-703418.5 HIG

—

———Use after free in Microsoft Edge (Chromium-based) allows an authorized attacker to execute code over a network.5h CVE-2026-578427.0 HIG

—

———NetBSD contains a use-after-free and double-free vulnerability in msg_recv_copyin() within the COMPAT_NETBSD32 compatibility layer due to a missing return statement before the cleanup label on the success path. Any local user able to execute a 32-bit binary on a 64-bit NetBSD system can trigger a kernel panic or memory corruption by calling recvmsg() with msg_iovlen between 9 and IOV_MAX, causing the kernel to access a freed iovec buffer and subsequently free the same allocation a second time.18h CVE-2026-781337.5 HIG

—

——0libcharon in strongSwan 6.0.0 through 6.0.7 has a use-after-free in IKEv2 rekeying collision handling.16h CVE-2026-781235.9 MED

—

——0strongSwan 5.0.2 through 6.0.7 has an Expired Pointer Dereference in PKCS#7 parsing in the openssl plugin.18h CVE-2026-457525.9 MED

—

——0Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Starting in version 8.0.0 and prior to version 8.0.5, when certain detection transforms are chained, the decompress transform pipeline could read from an inspection buffer after it had been reallocated and freed. The issue is reached during network traffic processing, but requires a malicious rule as Suricata will crash whatever the traffic. Version 8.0.5 contains a fix. As a workaround, avoid rules that chain `gunzip` or `zlib_deflate` with `max-size` bigger than 4096 after another transform.15h CVE-2026-457515.9 MED

—

——0Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5, Suricata's inspection-buffer helper could leave an inspection pointer referencing freed memory after a chained transform caused the backing buffer to be reallocated. The issue is reached during a specific network traffic processing, and requires a specific but not malicious rule. Versions 7.0.16 and 8.0.5 contain a fix. As a workaround, avoid rules that chain `dotprefix` transform after another one.17h