CVE-2024-36904: Linux Kernel Use-After-Free Vulnerability

CVE-2024-36904 Overview

CVE-2024-36904 is a use-after-free vulnerability in the Linux kernel's TCP implementation, specifically within the tcp_twsk_unique() function. The flaw arises from a race condition introduced by commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), where inet_twsk_hashdance() sets a TIME-WAIT socket's sk_refcnt after placing it into the ehash and releasing the bucket lock. This creates a small race window where other threads could attempt to reuse the port during connect() and call sock_hold() on a TIME-WAIT socket with a zero reference count, leading to reference count corruption and subsequent use-after-free conditions.

Critical Impact

Local attackers with low privileges can exploit this race condition to trigger use-after-free memory corruption, potentially leading to privilege escalation, arbitrary code execution, or system crashes on affected Linux systems.

Affected Products

• Linux Kernel (multiple versions including 6.9-rc1 through 6.9-rc7)
• Debian Linux 10.0
• Various Linux distributions shipping vulnerable kernel versions

Discovery Timeline

• 2024-05-30 - CVE-2024-36904 published to NVD
• 2026-01-22 - Last updated in NVD database

Technical Details for CVE-2024-36904

Vulnerability Analysis

This vulnerability is classified as CWE-416 (Use After Free). The root issue lies in the TCP/DCCP timewait socket handling code where an optimization to reduce atomic operations inadvertently created a dangerous race condition. When a TIME-WAIT socket is added to the established hash table (ehash), its reference count (sk_refcnt) is set after the bucket lock is released rather than before. This ordering allows concurrent threads executing connect() to observe the socket in the hash table while its reference count is still zero.

When tcp_twsk_unique() calls sock_hold() on this zero-refcount socket, it incorrectly increments the reference count. The subsequent sock_put() call causes a reference count underflow, which eventually leads to a use-after-free condition when the memory is accessed after being freed.

Root Cause

The vulnerability stems from an unsafe ordering of operations in inet_twsk_hashdance(). The function was modified to set the socket's reference count after inserting it into the hash table and releasing the bucket lock. This violates the principle that shared data structures should only contain fully-initialized objects. The race window, while small, is exploitable under high concurrency scenarios, particularly on systems with heavy TCP connection churn where port reuse is frequent.

Attack Vector

Exploitation requires local access to the system with the ability to create TCP connections. An attacker can trigger the race condition by rapidly initiating connections that attempt to reuse ports currently in the TIME-WAIT state. The attack involves:

1. Creating multiple concurrent threads that establish and tear down TCP connections
2. Timing connection attempts to hit the window where TIME-WAIT sockets have been added to ehash but not yet had their reference count set
3. Triggering the sock_hold() call on a zero-refcount socket through tcp_twsk_unique()
4. Observing the reference count underflow when sock_put() is called

The kernel warning message "refcount_t: addition on 0; use-after-free" indicates when this condition has been triggered, as captured in the stack trace showing the call path through tcp_twsk_unique(), __inet_check_established(), __inet_hash_connect(), and ultimately tcp_v4_connect().

Detection Methods for CVE-2024-36904

Indicators of Compromise

• Kernel warning messages containing "refcount_t: addition on 0; use-after-free" in system logs
• Stack traces in dmesg showing refcount_warn_saturate called from tcp_twsk_unique()
• Unexpected system crashes or kernel panics during high TCP connection activity
• Memory corruption symptoms manifesting as seemingly unrelated kernel crashes

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for refcount warning messages from lib/refcount.c
• Deploy kernel tracing tools (ftrace, eBPF) to monitor tcp_twsk_unique() and sock_hold() call patterns
• Implement SentinelOne's kernel-level monitoring to detect anomalous memory access patterns in TCP stack functions
• Configure crash dump analysis to identify use-after-free signatures in kernel memory

Monitoring Recommendations

• Enable kernel address sanitizer (KASAN) in development environments to catch use-after-free conditions early
• Set up alerting on kernel panic events and analyze crash dumps for TCP stack involvement
• Monitor for unusual patterns of TCP connection failures or socket errors that could indicate exploitation attempts
• Use SentinelOne Singularity platform's behavioral AI to detect privilege escalation attempts following memory corruption

How to Mitigate CVE-2024-36904

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the fix using refcount_inc_not_zero() in tcp_twsk_unique()
• Apply vendor-specific security updates from your Linux distribution
• For systems that cannot be immediately updated, consider limiting local user access to reduce attack surface
• Monitor systems for signs of exploitation while patches are being deployed

Patch Information

The fix modifies tcp_twsk_unique() to use refcount_inc_not_zero() instead of sock_hold(). This atomic operation safely checks if the reference count is non-zero before incrementing, returning false if the socket has a zero reference count. When the function returns false, port reuse is abandoned, preventing the use-after-free condition.

Multiple kernel patches have been released across stable branches:

• Linux Kernel Commit 13ed7df
• Linux Kernel Commit 1796ca9c
• Linux Kernel Commit 1d9cf07
• Linux Kernel Commit 27b0284
• Linux Kernel Commit 517e32e
• Linux Kernel Commit 6e48faa
• Linux Kernel Commit 84546cc
• Linux Kernel Commit f2db723

Debian users should refer to the Debian LTS Announcement for distribution-specific patches. NetApp customers should consult NetApp Security Advisory ntap-20240905-0004.

Workarounds

• Reduce TCP connection concurrency in high-risk environments to minimize the race window
• Implement network segmentation to limit which users can initiate TCP connections on vulnerable systems
• Consider enabling SELinux or AppArmor policies to restrict local user capabilities for socket operations
• Monitor and audit local user activities that involve high-frequency TCP connection establishment

# Check current kernel version for vulnerability status
uname -r

# Check for available kernel updates (Debian/Ubuntu)
apt update && apt list --upgradable | grep linux-image

# Check for available kernel updates (RHEL/CentOS)
yum check-update kernel

# Monitor kernel logs for exploitation indicators
dmesg | grep -i "refcount_t: addition on 0"