CVE-2024-26852 in Linux
Zusammenfassung
von VulDB • 30.05.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 by task 23037, then freed by task 16, and subsequently accessed (likely read or written) by the current context (indicated by the register state and crash). - **Location:** The object was allocated in `fib6_info_alloc` (net/ipv6/ip6_fib.c) and freed via the slab allocator. The access that triggered the UAF detection is not fully shown in the truncated stack, but the allocation stack shows it was triggered by an IPv6 route addition (`inet6_rtm_newroute`).
---
### **Detailed Analysis**
#### **1. The Allocated Object** - **Type:** `struct fib6_info` (IPv6 FIB info structure). - **Allocation Source:** ```c fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ``` - **Triggering Operation:** The allocation was triggered by a user-space process adding an IPv6 route via `rtnetlink`: ``` inet6_rtm_newroute -> ip6_route_multipath_add -> ip6_route_info_create -> fib6_info_alloc ``` This means a user-space program (e.g., `ip -6 route add ...`) caused the kernel to allocate this structure.
#### **2. The Freeing Event** - **Freed by Task 16:** The object was freed by a different task (PID 16). The stack trace is truncated, but it ends with: ``` poison_slab_object+0xa6/0xe0 m ``` This confirms the object was returned to the slab allocator (likely `fib6_node_cache` or similar slab cache used for `fib6_info`).
#### **3. The Use-After-Free** - **Current State:** The register dump (`ORIG_RAX: 000000000000002e`, `RAX: ff...da`) suggests the CPU was executing code that accessed memory. The `RAX` value `ff...da` is likely a KASAN poison pattern (`0xff...da` is often used by KASAN to mark freed memory as "poisoned" to detect accesses). - **Implication:** Some code path (not fully shown in the truncated stack) is dereferencing a pointer to this `fib6_info` structure after it has been freed by task 16.
---
### **Root Cause Hypothesis**
This is a classic **race condition** or **reference counting bug** in the IPv6 routing code. Possible scenarios:
1. **Missing Reference Count:** - Task 23037 creates a route and gets a pointer to `fib6_info`. - Task 16 deletes the route (or a conflicting route), freeing the `fib6_info`. - Task 23037 (or another task holding a stale pointer) tries to use the route, accessing the freed memory.
2. **Asynchronous Cleanup:** - IPv6 route deletion might be asynchronous or involve deferred work. If a pointer to `fib6_info` is stored in a structure that is not properly synchronized (e.g., in a neighbor cache, routing table, or netlink socket), it can be accessed after free.
3. **Specific Bug in `ip6_route_multipath_add` or Related Code:** - Since the allocation was triggered by `ip6_route_multipath_add`, there might be a bug where a partially constructed route is freed while another part of the system is still referencing it.
---
### **How to Fix/Investigate Further**
1. **Get the Full Free Stack:** The provided stack trace is truncated at `poison_slab_object`. You need the full stack trace of the **free** operation to see *why* and *where* task 16 freed the object. Look for: ``` kasan_report mm/kasan/common.c:79 [inline]
__asan_report_load8_noabort+0x4d/0x80 mm/kasan/report.c:305 ... (accessing code) ... ``` And the **free** stack: ``` kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.