CVE-2026-53175

What it actually does

This is a Linux kernel use-after-free in the IP fragment reassembly subsystem during network namespace teardown. When a network namespace is being destroyed, the kernel flushes incomplete fragment queues and frees queued socket buffers, but vulnerable kernels leave internal fragment queue pointers referencing freed memory. A packet fragment that already found the queue before the flush can later resume, acquire the queue lock, and dereference or write through those stale pointers. The affected shared code path is used by IPv4 fragmentation, IPv6 fragmentation, nf_conntrack IPv6 reassembly, and 6LoWPAN reassembly. Successful exploitation could cause kernel memory corruption, kernel crash, or potentially privilege escalation depending on allocator state, hardening, and exploit reliability.

Why it matters to the business

The most likely operational impact is denial of service through kernel crashes or instability on systems processing fragmented network traffic while network namespaces are being created and destroyed, such as container hosts, Kubernetes nodes, CI runners, network appliances, and systems using namespace-heavy isolation. Although public exploit maturity is currently listed as none, the flaw is in core Linux networking code and was published 47 days ago, so organizations should treat it as a routine kernel patching priority, especially where untrusted users or workloads can create network namespaces or send crafted fragmented traffic.

How an attack unfolds

An attacker attempts to create a race between fragmented network packet processing and teardown of a Linux network namespace. First, they cause or wait for a target network namespace to contain an incomplete fragment queue, such as by sending IPv4 or IPv6 fragments that do not complete reassembly. During namespace teardown, the kernel flushes the fragment queue and frees the queued socket buffers. In the vulnerable code path, some queue pointers still reference the freed buffers. If another fragment had already found the queue before the flush but had not yet taken the queue lock, it can resume after the flush, pass the completion check, and enter fragment insertion logic that reads from or writes to the freed buffer. In a simple case this produces a kernel oops, panic, or KASAN report. A more advanced attacker would try to shape heap allocations around the race to turn the stale pointer access into controlled memory corruption, but exploitation is timing-dependent and no public mature exploit is indicated by the provided data.

How to fix it

Apply Linux kernel updates from the relevant distribution or vendor that include the fix for the inet fragment queue teardown use-after-free. Because the provided input does not list affected package names or exact fixed versions, use vendor advisories for the deployed kernel stream and confirm that the patch resets rb_fragments, fragments_tail, and last_run_head in inet_frag_queue_flush() after flushing queued fragments. Prioritize upgrades on container hosts, orchestration nodes, virtualization platforms, CI/CD runners, network appliances, and systems allowing untrusted users or workloads to create network namespaces. If immediate patching is not possible, reduce exploitability by restricting untrusted namespace creation, limiting CAP_NET_ADMIN and similar privileges, disabling unprivileged user namespaces where operationally acceptable, minimizing exposure to fragmented traffic at network boundaries where safe, and monitoring for kernel crashes or networking oops events. Blocking all IP fragments can disrupt legitimate traffic and should be tested before broad deployment.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the fix, not merely that a package is installed on disk; compare `uname -r` and package inventory against the vendor advisory. Where source or build metadata is available, verify that inet_frag_queue_flush() clears the fragment queue state after freeing queued skbs, including rb_fragments, fragments_tail, and last_run_head. Reboot into the fixed kernel if required by the platform. Validate that container hosts and namespace-heavy systems are no longer running vulnerable kernels. Review firewall or network controls only as compensating measures; they do not prove remediation. For regression validation in test environments, exercise namespace create/destroy workflows with fragmented IPv4 and IPv6 traffic and confirm there are no kernel oops, panic, KASAN, or slab use-after-free messages associated with the fragment reassembly paths.

Typical attack path

1. Gain the ability to influence fragmented IPv4, IPv6, nf_conntrack IPv6, or 6LoWPAN traffic reaching a Linux network namespace.
2. Cause an incomplete fragment queue to exist by sending partial or malformed fragment sequences.
3. Trigger, induce, or wait for network namespace teardown, for example through container, sandbox, or namespace lifecycle activity.
4. Race an additional fragment so it has already located the fragment queue before teardown flushing but resumes after queued buffers have been freed.
5. Cause the kernel fragment insertion path to dereference or modify stale pointers that still reference freed socket buffers.
6. Achieve a kernel crash or, with significantly more reliability work, attempt kernel memory corruption for privilege escalation.

How to detect it

Look for evidence of prior exploitation primarily through host-level kernel telemetry, because this flaw does not create a distinctive application log entry. Review kernel logs, journald, dmesg, crash dumps, panic records, hypervisor reset events, and EDR kernel-event telemetry for use-after-free, slab corruption, general protection faults, or oops traces involving IP fragment reassembly and network namespace teardown. Pay particular attention to container hosts or systems with frequent namespace creation and destruction around the time of unexplained crashes. Network telemetry may show unusual volumes of incomplete, overlapping, malformed, or repeated IPv4/IPv6 fragments shortly before a crash, but fragmented traffic alone is not proof of exploitation. If KASAN, KFENCE, kernel crash dump collection, or panic-on-oops telemetry is enabled, search for stack frames referencing inet_frag_queue_flush(), inet_frag_queue_insert(), fqdir_pre_exit(), IPv6 fragment reassembly, nf_conntrack_reasm6, or 6LoWPAN reassembly. Correlate these events with container stop/delete events, namespace teardown activity, and external or internal sources sending fragmented packets.

• BUG: KASAN: slab-use-after-free
• slab-use-after-free
• use-after-free in inet_frag_queue_insert
• inet_frag_queue_insert
• inet_frag_queue_flush
• fqdir_pre_exit
• nf_conntrack_reasm6
• ip6_frag_queue
• ip_frag_queue
• inet_frag_find
• fragments_tail
• last_run_head
• general protection fault
• kernel BUG at net/ipv4/inet_fragment.c
• kernel BUG at net/ipv6/reassembly.c
• Oops:
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems that run containers, sandboxes, network namespaces, conntrack, IPv6, or 6LoWPAN and prioritize them for kernel patching.
• Apply vendor kernel updates containing the inet fragment queue flush fix and reboot systems into the fixed kernel.
• Restrict untrusted creation of user and network namespaces where possible, especially on multi-tenant or shared compute hosts.
• Limit CAP_NET_ADMIN and equivalent container privileges to trusted workloads only.
• Increase monitoring for kernel oops, panic, KASAN, and slab use-after-free events involving inet fragment reassembly functions.
• Review perimeter and host firewall handling of fragmented traffic; consider dropping suspicious fragments where this will not break required services.
• Track vendor advisories for exact fixed kernel versions because the affected_products and fixed_versions fields were not provided in the input.
• Treat the issue as moderate urgency: no KEV listing, no ransomware association, low EPSS, and no known public exploit maturity, but broad kernel prevalence and potential kernel memory corruption justify timely remediation.