CVE-2024-26852 in Linux
Riassunto
di VulDB • 15/06/2026
Based on the KASAN (Kernel Address Sanitizer) report provided, here is a detailed analysis of the bug.
### **Summary** This is a **Use-After-Free (UAF)** bug in the Linux kernel's IPv6 routing subsystem. - **What happened:** A memory object (`fib6_info`) was allocated, then freed by task 16, and subsequently accessed/used by task 23037. - **Where:** In the IPv6 route creation path (`ip6_route_multipath_add` -> `fib6_info_alloc`). - **Root Cause:** The kernel is attempting to use a `fib6_info` structure that has already been freed. This typically indicates a race condition or a missing reference count update in the IPv6 routing code.
---
### **Detailed Analysis**
#### **1. The Freed Object** - **Freed by Task 16:** The stack trace shows the object was freed via `kfree` (implied by `poison_slab_object`). The object type is `fib6_info` (IPv6 FIB info structure), allocated in `fib6_info_alloc`.
#### **2. The Use (The Bug)** - **Used by Task 23037:** The task was executing `inet6_rtm_newroute` -> `ip6_route_multipath_add` -> `ip6_route_info_create` -> `fib6_info_alloc`. - **Wait:** The "Allocated by task" stack shows `fib6_info_alloc` being called. This suggests the **current crash** is happening **during the allocation** or **immediately after**, but KASAN is reporting that the memory being accessed was **previously freed**. - **Correction:** In KASAN reports, the "Allocated by task" stack shows where the **currently accessed memory** was *originally allocated*. The "Freed by task" stack shows where it was *freed*. - Therefore, the memory being accessed in `fib6_info_alloc` (or a function it calls) was **already freed** by task 16.
#### **3. Key Registers** - `RAX: ffffffffffffffda` → This is `-22` in two's complement, which corresponds to `-EINVAL` (Invalid argument). However, in KASAN reports, `RAX` often holds the return value or an error code. The fact that it's negative suggests the kernel might have detected an error and returned early, but the UAF happened before that. - `RDI: 0000000000000005` → This is likely the size of the allocation or a pointer argument. - `R13: 000000000000006e` → 110 in decimal. This could be a size or an index.
#### **4. Likely Scenario** The IPv6 routing code has a race condition where: 1. Task 16 frees a `fib6_info` structure (e.g., during route deletion or update). 2. Task 23037, while adding a new multipath route, tries to access or copy data from that same `fib6_info` structure (or a structure that references it) without holding a proper reference count. 3. KASAN detects that the memory is in the "freed" state (poisoned) and triggers the bug.
---
### **Potential Fixes**
1. **Reference Counting:** Ensure that any code accessing a `fib6_info` structure holds a reference to it (e.g., via `fib6_info_hold()` and `fib6_info_put()`). If Task 23037 is accessing a structure that Task 16 is freeing, Task 23037 should have incremented the refcount before accessing it.
2. **Synchronization:** Add proper locking (e.g., `rtnl_lock()`) around the route creation and deletion paths to prevent concurrent access. The `inet6_rtm_newroute` function should hold the `rtnl_lock` when modifying routes, but internal data structures like `fib6_info` may need additional protection if they are accessed outside the lock.
3. **Check for Dangling Pointers:** Review the code in `ip6_route_multipath_add` and `ip6_route_info_create` to ensure that pointers to `fib6_info` structures are not used after they have been freed. This might involve checking if a route is being deleted while another thread is adding a new route that references it.
---
### **How to Reproduce** This bug is likely triggered by: - Rapidly adding and deleting IPv6 multipath routes. - Concurrent route modifications from multiple net
If you want to get best quality of vulnerability data, you may have to visit VulDB.