CVE-2024-47684 in Linux
要約
〜によって VulDB • 2026年05月29日
Based on the kernel log snippet provided, here is an analysis of the crash.
### **Summary** This is a **Kernel Oops/Panic** caused by a **Null Pointer Dereference** (or invalid memory access) in the **TCP/IP stack** during a **TCP Retransmission Timeout (RTO)** handling.
The crash occurs in `tcp_send_loss_probe()` while processing a timer event (`tcp_write_timer`).
---
### **Detailed Stack Trace Analysis**
1. **Root Cause: Page Fault** * `page_fault+0x34/0x40` * `do_page_fault+0x2c/0xe0` * `__do_page_fault+0x58/0x90` * `bad_area_nosemaphore+0x16/0x20` * `do_user_addr_fault+0x267/0x450` * **Interpretation:** The CPU tried to access a memory address that was not mapped or invalid. The `bad_area_nosemaphore` flag indicates this happened in a context where sleeping is not allowed (atomic context), which is typical for timer handlers.
2. **Triggering Function: TCP Loss Probe** * `tcp_send_loss_probe+0x10b/0x220` * **Interpretation:** The kernel was attempting to send a "loss probe" packet. This is part of TCP's Fast Retransmit/Recovery mechanism. When a packet is lost, the sender sends a probe to confirm the loss and trigger retransmission.
3. **Context: TCP Write Timer** * `tcp_write_timer+0x9e/0xe0` * `tcp_write_timer_handler+0x1b4/0x240` * `call_timer_fn+0x32/0x130` * `__run_timers.part.0+0x180/0x280` * **Interpretation:** The crash happened in a **timer interrupt context**. The TCP socket's write timer fired, indicating a timeout (likely RTO - Retransmission Timeout).
4. **Network Stack Context** * `ipv6_list_rcv+0x112/0x140` * `ip6_sublist_rcv_finish+0x3d/0x50` * `ip6_protocol_deliver_rcu+0x4e0/0x4e0` * **Interpretation:** The system was also processing incoming IPv6 packets (`ipv6_list_rcv`) when the crash occurred. This suggests the bug might be related to concurrent access to a socket structure that was being modified by both the incoming packet handler and the outgoing timer handler.
---
### **Likely Root Cause**
The most probable cause is a **race condition** or **use-after-free** in the TCP socket structure (`struct sock` or `struct tcp_sock`).
* **Scenario:** A TCP socket is being closed or reset (possibly due to the incoming IPv6 packet processing) while the TCP write timer is still active and trying to send a loss probe. * **Specific Bug:** The `tcp_send_loss_probe()` function likely dereferenced a pointer (e.g., `tp->snd_una`, `tp->snd_nxt`, or a sk_buff) that had already been freed or invalidated by another CPU core or interrupt context.
### **Common Fixes/Workarounds**
1. **Update Kernel:** This is a known class of bugs in older Linux kernels. Check if your kernel version is affected by known TCP timer race conditions. * **Action:** Upgrade to the latest stable kernel for your distribution. 2. **Check for Known CVEs:** Search for CVEs related to `tcp_send_loss_probe` and `tcp_write_timer` in your kernel version. 3. **Disable TCP Timestamps or SACK:** In some cases, disabling TCP SACK (`net.ipv4.tcp_sack=0`) or Timestamps (`net.ipv4.tcp_timestamps=0`) can mitigate race conditions, though this is a workaround, not a fix. 4. **Check for Network Driver Issues:** If the crash is triggered by specific IPv6 traffic, ensure your network drivers are up to date.
### **How to Debug Further**
1. **Get Full Oops Details:** The truncated log hides the **faulting address** and **register state**. Look for lines like: ``` Oops: 0002 [#1] SMP PTI
CPU: 5 PID
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.