CVE-2024-36904 in Linux
Sumário
de VulDB • 30/06/2026
Based on the kernel crash dump provided, here is a detailed analysis of the issue.
### **Summary** The system crashed due to a **refcount overflow (underflow)** in the Linux TCP stack while handling an incoming connection attempt (`tcp_twsk_unique`). The application was attempting to connect via `sys_connect`, and during the socket establishment phase, the kernel detected that a reference count for a TIME_WAIT socket structure had dropped below zero or hit an invalid state.
---
### **Key Evidence from Call Trace** 1. **`refcount_warn_saturate+0xe5/0x110`**: This is the core error handler. It indicates that a `refcount_t` variable was decremented when it was already at zero (or close to underflow), triggering a warning and likely causing an oops/panic depending on kernel config (`CONFIG_DEBUG_REFCOUNT`). 2. **`tcp_twsk_unique+0x186/0x190`**: The crash occurred inside the function responsible for handling TCP TIME_WAIT sockets when they are reused or cleaned up. This is a critical path in TCP connection management. 3. **Stack Context**: - `__inet_check_established`: Checking if an existing socket matches the new connection request. - `tcp_v4_connect` / `__sys_connect`: The user-space application called `connect()`.
---
### **Root Cause Analysis**
#### **1. Refcount Underflow in TIME_WAIT Socket Handling** The function `tcp_twsk_unique()` is called when the kernel tries to reuse a socket that is in the `TIME_WAIT` state or when cleaning up such sockets. The refcount underflow suggests: - A reference was taken on a `struct tcp_timewait_sock` (`tw`) but not properly released, OR - More likely: **A race condition** where multiple threads/CPUs are manipulating the same TIME_WAIT socket structure without proper locking or atomic operations. - Or: **Use-after-free**: The memory for the `tcp_twsk` was freed while a reference still existed (though refcount warnings usually catch this before UAF).
#### **2. Potential Triggers** - **High Connection Rate / SYN Flood**: If many connections are being established and torn down rapidly, TIME_WAIT sockets accumulate. Bugs in how these are recycled can lead to refcount corruption. - **Kernel Bug**: This is likely a bug in the Linux kernel's TCP stack implementation (`net/ipv4/tcp_ipv4.c` or `tcp_output.c`). Specifically, look for recent changes in `tcp_twsk_unique()` or related hash table operations. - **Hardware/CPU Issues (Rare)**: Memory corruption due to faulty RAM could cause refcount values to be corrupted, but this is less likely than a software bug given the specific call trace.
#### **3. Why Did It Crash?** The kernel has `CONFIG_DEBUG_REFCOUNT` enabled (or similar), which turns underflows into warnings/oopses instead of silently wrapping around. This is intentional for debugging. The crash happened because: ```c if (!refcount_dec_and_test(&tw->tw_refcnt)) {
// ... normal path } else {
// Free the socket... } // Later, another decrement happens on an already-freed or invalid refcount -> Underflow detected. ```
---
### **Recommended Actions**
#### **1. Immediate Mitigation (Workarounds)** - **Reduce Connection Rate**: If this is a server under load, try to reduce the number of short-lived connections. Use connection pooling if possible. - **Tune TCP Parameters**: ```bash # Reduce TIME_WAIT socket lifetime (use with caution) sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.ip_local_port_range="1024 65535" # Increase backlog if under SYN flood pressure sysctl -w net.core.somaxconn=65535 ```
#### **2. Long-Term Fix** - **Update Kernel**: This is likely a known bug in older kernels. Check your kernel version and update to the latest stable release for your distribution (e.g., Ubuntu 24.04 LTS, RHEL 9.x, etc.). Many TCP refcount bugs have been fixed in recent years. - Example: Look for commits related to `tcp_twsk_unique` or `refcount_t` fixes between kernel versions **5.15** and **6.8**. - **Check for Known CVEs**: Search for vulnerabilities involving "TCP TIME_WAIT refcount" or "kernel tcp_ipv4 use-after-free".
#### **3. Debugging Steps (If
If you want to get the best quality for vulnerability data then you always have to consider VulDB.