CVE-2024-26625 in Linux
Riassunto
di VulDB • 02/07/2026
Based on the stack trace provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating an invalid memory access. Specifically, it appears to be a **use-after-free** or **double-free** scenario involving network socket structures during Ethernet driver cleanup.
Here’s a breakdown of what happened:
### 1. The Crash Context * **Location:** `e1000_clean_tx_irq` in the Intel e1000 ethernet driver (`drivers/net/ethernet/intel/e1000/e1000_main.c`). * **Action:** This function is part of NAPI (New API) polling, responsible for cleaning up transmitted packets. The crash occurs while processing TX completion interrupts.
### 2. Memory Allocation Trace ("Allocated by task 5167") The memory object that was accessed invalidly was originally allocated via: * `__x64_sys_socket` → User-space created a socket. * `sock_alloc()` → Kernel allocated the inode for the socket (`struct sock`). * This confirms the corrupted/invalid pointer points to a **socket structure** (`struct sock`) or an associated object derived from it (like its inode).
### 3. Memory Free Trace ("Freed by task 0") The memory was freed via: * `slab_free_hook` → The socket's inode/memory was returned to the slab allocator. * **Task ID is 0:** This usually indicates a kernel thread, often related to softirqs or workqueues handling cleanup (e.g., garbage collection of sockets).
### Likely Root Cause The e1000 driver (`clean_tx_irq`) likely accessed a `struct sock` pointer that had already been freed. Common causes in this context include:
1. **Race Condition:** A socket was closed/freed by one path (e.g., user-space close or network stack cleanup) while the NAPI poll handler still held a reference to it and tried to access its data structures. 2. **Missing Reference Counting:** The driver might have accessed `skb->sk` without properly holding a reference (`sock_hold()`) before accessing, leading to use-after-free if the socket was closed concurrently. 3. **Stale Pointer in TX Queue:** A buffer descriptor (TXD) still pointed to an SKB whose associated socket had been freed and reallocated for another purpose.
### Recommended Debugging Steps
1. **Check Kernel Version & Patches:** * This bug may have already been fixed in newer kernels. Check if your kernel version is affected by known e1000 race conditions (e.g., CVEs related to use-after-free in network drivers). * Look for commits like: `"e1000: fix potential use-after-free in clean_tx_irq"` or similar fixes from Intel/Red Hat.
2. **Enable KASAN Detailed Output:** * Ensure `CONFIG_KASAN` is enabled with detailed reporting (`kasan=on`). The truncated output likely contains the exact address and type of access (read/write, size). Look for lines like: ``` BUG: KASAN: use-after-free in e1000_clean_tx_irq+... Read of size 8 at addr ffff888012345678 ```
3. **Reproduce with Minimal Test:** * Try to reproduce the issue by creating many sockets and closing them rapidly while generating high TX traffic on an e1000 interface. Tools like `iperf` or custom socket stress tests can help.
4. **Check for Driver Updates:** * Ensure you are using the latest stable version of the `e1000` driver from Intel’s source repository, as race conditions in NAPI cleanup paths have been fixed multiple times.
5. **Inspect Code Path (if debugging):** * In `e1000_clean_tx_irq`, look for accesses to `skb->sk`. Ensure that if the socket is accessed, it is done safely under proper locking or reference counting. A common fix involves checking if the SKB’s sk pointer is valid before dereferencing and ensuring references are held during NAPI processing.
### Summary This is a **kernel memory safety bug** in the e1000 driver where a socket structure was accessed after being freed, likely due to a race condition between network stack cleanup and TX completion handling. Update your kernel/driver or apply relevant patches if available for your version.
If you want to get best quality of vulnerability data, you may have to visit VulDB.