CVE-2024-26852 in Linux
Sumário
de VulDB • 27/05/2026
This is a **KASAN (Kernel Address Sanitizer)** report indicating a **Use-After-Free (UAF)** bug in the Linux kernel's IPv6 routing subsystem.
### ???? Summary of the Bug - **Type**: Use-After-Free (UAF) - **Component**: IPv6 Routing (`net/ipv6/route.c`, `net/ipv6/ip6_fib.c`) - **Trigger**: A user-space process sends an `RTM_NEWROUTE` message via netlink to add an IPv6 route. - **Root Cause**: The kernel allocated a `fib6_info` structure, but it was freed before being fully used or while still referenced. The current crash occurs when the kernel tries to access this freed memory.
---
### ???? Key Stack Traces
#### 1. **Allocation Stack** (Task 23037) The memory was allocated via: ``` kzalloc → fib6_info_alloc → ip6_route_info_create → ip6_route_multipath_add → inet6_rtm_newroute ``` This happens when a user-space program adds an IPv6 route using `ip route add ...` or similar netlink commands.
#### 2. **Free Stack** (Task 16) — *Truncated but critical* The memory was freed by **Task 16**, which is likely a different kernel thread or process handling route deletion, cleanup, or a race condition. The truncation hides the exact free path, but it’s likely: ``` kfree → fib6_info_destroy → ... → ip6_route_del or similar ```
---
### ???? Likely Root Cause This is a **race condition** between: - **Task 23037**: Adding a new IPv6 route (`inet6_rtm_newroute`) - **Task 16**: Deleting or cleaning up an existing route (possibly the same route or a related one)
The `fib6_info` structure is allocated for the new route, but before it’s fully initialized or inserted into the routing table, another task frees it. When Task 23037 continues execution and accesses the freed memory, KASAN detects the UAF.
Common scenarios: 1. **Race between add and delete**: A route is added and immediately deleted by another thread. 2. **Error path bug**: If `ip6_route_info_create` fails partially, the allocated `fib6_info` might be freed incorrectly while still referenced. 3. **Missing reference counting**: The `fib6_info` might not be properly refcounted, leading to premature free.
---
### ????️ How to Fix 1. **Check Reference Counting**: - Ensure `fib6_info` is properly refcounted (`fib6_info_hold()` / `fib6_info_put()`). - Verify that all paths (success, error, cleanup) correctly manage references.
2. **Add Synchronization**: - Use proper locking (e.g., `rtnl_lock()`) to prevent concurrent add/delete operations on the same route. - Ensure that route modifications are serialized.
3. **Audit Error Paths**: - In `ip6_route_info_create` and `fib6_info_alloc`, ensure that if an error occurs after allocation, the memory is freed **only if** it’s not already referenced elsewhere.
4. **Check for Double-Free or Premature Free**: - Trace Task 16’s free stack to see if it’s freeing a route that’s still in use.
---
### ???? Example Patch Direction If the issue is in `ip6_route_info_create`, ensure that: ```c struct fib6_info *fi = fib6_info_alloc(...); if (!fi) return NULL;
// ... initialization ...
// Ensure no other task can free 'fi' before it's inserted if (insert_into_table(fi) < 0) {
fib6_info_put(fi); // Properly release reference return ERR_PTR(-error); } ```
---
### ???? Next Steps for Debugging 1. **Get the Full Free Stack**: - The free stack is truncated. Use `dmesg` or `kasan` logs to get the complete backtrace of Task 16.
2. **Reproduce with `CONFIG_KASAN`**: - Run the kernel with KASAN enabled to get precise details.
3. **Check for Known Bugs**: - Search for similar bugs in the Linux kernel git history (e.g., commits fixing UAF in `ip6_fib.c`).
4. **Use `lockdep`**: - Enable `CONFIG_LOCKDEP` to detect locking issues that might cause races.
---
### ???? Related Kernel Code
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.