CVE-2026-23391: Linux Kernel Netfilter DOS Vulnerability

CVE-2026-23391 Overview

A vulnerability has been identified in the Linux kernel's netfilter subsystem, specifically within the xt_CT (Connection Tracking) module. The vulnerability occurs when template rules are removed while packets are still enqueued in the nfqueue (netfilter queue). Templates may reference objects such as connection tracking helpers and timeout policies that can be deallocated during module removal or administrative actions, potentially leading to use-after-free conditions when the enqueued packets are later processed.

Critical Impact

Pending packets in the netfilter queue may reference deallocated helper modules or timeout policies after template removal, potentially causing kernel crashes or memory corruption.

Affected Products

• Linux kernel with netfilter xt_CT module enabled
• Systems using nfqueue with connection tracking templates
• Linux distributions with nfnetlink_cttimeout functionality

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23391 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23391

Vulnerability Analysis

The vulnerability resides in the Linux kernel's netfilter connection tracking extension (xt_CT). When packets are processed through netfilter rules that utilize connection tracking templates, these templates maintain references to kernel objects including:

1. Connection tracking helpers - Modules that assist with protocol-specific connection tracking (e.g., FTP, SIP helpers)
2. Timeout policies - Custom timeout configurations managed by nfnetlink_cttimeout

The issue manifests when packets are enqueued in nfqueue for userspace processing while referencing these template objects. If the template rule is subsequently removed (for example, during iptables rule modification or module unloading), the referenced helper or timeout policy objects may be freed. When the enqueued packets are later dequeued and processed, they may attempt to access these freed memory regions.

The fix ensures that all pending enqueued packets referencing a template are flushed and properly handled when the template rule is removed, preventing use-after-free conditions.

Root Cause

The root cause is a race condition between packet processing through nfqueue and template rule removal. The netfilter framework did not properly synchronize the lifecycle of template-referenced objects with packets that may still hold references to these objects while waiting in userspace queues. Zone and event cache filter references are safe since they only copy values, but helper and timeout policy references maintain active pointers that become dangling when the underlying objects are freed.

Attack Vector

The attack vector requires local access to modify netfilter rules or trigger module removal operations. An attacker with sufficient privileges could potentially:

1. Create netfilter rules utilizing connection tracking templates with helpers
2. Trigger packet flow through these rules that gets enqueued in nfqueue
3. Remove the template rule or unload the helper module while packets are pending
4. Wait for the packets to be processed, triggering access to freed memory

The vulnerability mechanism involves the xt_CT target not properly flushing enqueued packets when templates are removed. This can occur during legitimate administrative operations such as firewall rule changes or kernel module management.

Detection Methods for CVE-2026-23391

Indicators of Compromise

• Kernel panic or oops messages referencing xt_CT, nf_conntrack, or nfnetlink_cttimeout modules
• Unexpected kernel crashes during firewall rule modifications
• System instability when loading/unloading netfilter connection tracking helper modules
• Memory corruption symptoms in kernel logs related to netfilter subsystem

Detection Strategies

• Monitor kernel logs (dmesg) for warnings or errors related to xt_CT or connection tracking
• Implement auditd rules to track netfilter rule modifications (iptables, nftables commands)
• Deploy kernel crash dump analysis to identify use-after-free patterns in netfilter code paths
• Use kernel debugging features like KASAN (Kernel Address Sanitizer) to detect memory safety violations

Monitoring Recommendations

• Enable kernel crash reporting mechanisms to capture diagnostic information
• Monitor for unusual patterns of netfilter rule changes followed by system instability
• Implement alerting on kernel oops or panic events with netfilter-related call stacks
• Track module loading/unloading events for connection tracking helpers

How to Mitigate CVE-2026-23391

Immediate Actions Required

• Apply the kernel patches from the stable kernel git repositories
• Avoid modifying netfilter rules while traffic is actively being processed through nfqueue
• Consider temporarily disabling nfqueue usage if patching is not immediately possible
• Schedule maintenance windows for firewall rule changes to minimize active packet processing

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix ensures that pending enqueued packets are properly flushed when template rules are removed. Multiple kernel stable branches have received the fix:

• Kernel Git Commit 19a230d
• Kernel Git Commit 63b8097
• Kernel Git Commit 777d02e
• Kernel Git Commit cb54992
• Kernel Git Commit d2d0bae
• Kernel Git Commit f62a218

Update to a kernel version containing one of these commits to remediate the vulnerability.

Workarounds

• Avoid using nfqueue with connection tracking templates until patched
• Implement operational procedures to drain nfqueue before modifying CT template rules
• Consider using alternative packet filtering approaches that don't rely on xt_CT templates
• If using custom timeout policies via nfnetlink_cttimeout, avoid removing them while traffic is active

# Configuration example
# Flush nfqueue before removing CT template rules
# This reduces the window for the race condition

# Stop services that consume nfqueue packets
systemctl stop suricata  # or your nfqueue consumer

# Wait for queue to drain
sleep 5

# Now safe to modify iptables CT rules
iptables -D INPUT -j CT --helper ftp

# Restart services
systemctl start suricata