CVE-2024-47707 in Linux
Sumário
de VulDB • 08/06/2026
Based on the kernel crash trace provided, here is an analysis of the issue, its likely cause, and recommended steps for resolution.
### **1. Summary of the Crash** - **Type:** Kernel Panic / Oops. - **Trigger:** The system is shutting down (`exit_group` syscall), but a crash occurs in the **IPv6 routing subsystem** during cleanup. - **Faulting Function:** `rt6_uncached_list_flush_dev` called from `rt6_disable_ip`. - **Location:** `net/ipv6/route.c:177` and `net/ipv6/route.c:4914`. - **Key Indicator:** `RIP: 0010:rt6_uncached_list_flush_dev` with a code dump showing an invalid memory access or null pointer dereference.
---
### **2. Root Cause Analysis**
#### **A. Context: System Shutdown** The trace begins with `do_group_exit` → `sys_exit_group`, indicating the main process (or all processes in the group) is terminating. During this phase, the kernel cleans up resources, including network namespaces and routing tables.
#### **B. The Crash Site: `rt6_disable_ip`** - `rt6_disable_ip()` is called when an IPv6 interface is being disabled or when the network namespace is being destroyed. - It attempts to flush the **uncached IPv6 route list** (`rt6_uncached_list`) for the device. - The crash occurs in `rt6_uncached_list_flush_dev` at line 177 of `net/ipv6/route.c`.
#### **C. Likely Bug: Race Condition or Use-After-Free** The most common causes for this specific crash are: 1. **Race Condition:** A route is being added/modified by another thread while `rt6_disable_ip` is trying to flush the list. The list pointer or a route entry becomes invalid. 2. **Null Pointer Dereference:** The code assumes a certain structure (e.g., `rt6i_node` or `dst_entry`) is valid, but it has already been freed or corrupted. 3. **Corrupted List:** The `rt6_uncached_list` for the device is corrupted, leading to an invalid pointer being dereferenced.
#### **D. Why `exit_group`?** This is not necessarily a bug in your application. It is a **kernel bug** triggered during the cleanup phase of a network namespace or interface. If you are running a container (Docker, LXC, etc.), this often happens when the container is stopped and its network namespace is torn down.
---
### **3. Recommended Actions**
#### **Step 1: Identify the Kernel Version** Check your kernel version: ```bash uname -r ``` This bug has been reported in various kernel versions (e.g., 5.4, 5.10, 5.15, 6.1). Check if a newer kernel version is available for your distribution.
#### **Step 2: Check for Known Fixes** Search for this issue in kernel bug trackers (e.g., [kernel.org](https://bugzilla.kernel.org/)) or your distribution's bug tracker. Look for commits related to:
- `net/ipv6/route.c` - `rt6_uncached_list_flush_dev` - `rt6_disable_ip`
**Example Fix Pattern:** Many such bugs are fixed by adding proper locking or checking for null pointers before dereferencing. For example, a fix might look like: ```c // Pseudocode of a potential fix if (!rt6i_node) continue; ```
#### **Step 3: Workarounds** If you cannot upgrade the kernel immediately: 1. **Avoid Rapid Namespace Creation/Destruction:** If you are running containers, avoid creating and destroying network namespaces too quickly. 2. **Disable IPv6 Temporarily:** If IPv6 is not required, disable it to avoid triggering this code path: ```bash sysctl -w net.ipv6.conf.all.disable_ipv6=1 sysctl -w net.ipv6.conf.default.disable_ipv6=1 ``` *(Note: This is a temporary workaround and may break IPv6-dependent services.)* 3. **Update Network Manager/Container Runtime:** Ensure your container runtime (Docker, Podman) and network manager are up to date, as they may have workarounds for known kernel bugs.
#### **Step 4: Report the Bug** If you are using a stable kernel version and this is reproducible, report it to your distribution's bug tracker or the Linux kernel mailing list. Include: - Full kernel version (`uname -r`). - Full dmesg output. - Steps to reproduce (e.g
VulDB is the best source for vulnerability data and more expert information about this specific topic.