CVE-2024-26611 in Linux
Riassunto
di VulDB • 29/06/2026
Based on the kernel crash log and the description provided, this is a bug in the Linux Kernel's XDP (eXpress Data Path) implementation, specifically involving Zero-Copy (ZC) sockets (`xsk`) interacting with the `ice` network driver.
### Analysis of the Bug
1. **The Crash**: * The kernel panicked due to a page fault at address `0x34`. * The call trace shows: `__xdp_return()` -> `bpf_xdp_adjust_tail()` -> XDP program (`ice_clean_rx_irq_zc`). * The core issue is that `__xdp_return()` was called with a **NULL** `xdp_buff` pointer. This function expects a valid buffer to free resources (like pages or fragments). Passing NULL leads to an invalid memory access when it tries to dereference the buffer structure.
2. **The Root Cause**: * The bug occurs in Zero-Copy mode (`ice_clean_rx_irq_zc`). In ZC, buffers are managed by `xsk_buff_pool` and linked via a list (`xskb_list`) within each fragment node. * When `bpf_xdp_adjust_tail()` is called on an XDP packet that uses zero-copy buffers, it modifies the tail pointer of the buffer. This operation might invalidate or remove certain fragments from the standard XDP bookkeeping. * However, if a fragment/node was removed from the `xskb_list` (the list tracking which frags belong to this xsk_buff), but not properly cleaned up in the ZC-specific accounting before calling `__xdp_return()`, the subsequent free logic might try to operate on an orphaned or NULL reference. * Specifically, the description states: *"a node that represents the frag being removed has to be pulled out of xskb_list."* If this removal doesn't happen correctly in `bpf_xdp_adjust_tail()` for ZC buffers, the cleanup path (`__xdp_return`) gets confused or receives invalid state.
3. **The Fix Strategy**: * Introduce new helper functions to safely manipulate nodes within the `xskb_list` (the list of fragments associated with an XSK buffer). * Modify `bpf_xdp_adjust_tail()` to use these helpers when operating on Zero-Copy buffers (`xdp->rxq->zsk`). This ensures that any fragment node being adjusted or removed is correctly unlinked from the ZC tracking structure before the return path attempts to free resources.
### Proposed Patch Logic (Conceptual)
While I cannot generate a full, tested kernel patch without access to the specific source tree version and exact helper definitions, here is how such a fix would be structured based on your description:
#### 1. Add XSK List Manipulation Helpers In `net/xdp/xsk.c` or related header (`include/net/xdp_sock.h`), add functions to safely remove/add nodes from the `xskb_list`.
```c /* Example helper names - actual names depend on kernel version */ void xsk_buff_remove_frag_node(struct xdp_buffer *xdp, struct page *page); int xsk_buff_add_frag_node(struct xdp_buffer *xdp, struct page *page); ```
#### 2. Modify `bpf_xdp_adjust_tail()` in `net/core/filter.c`
The function needs to detect if it's dealing with a Zero-Copy buffer and handle the fragment list accordingly before calling `__xdp_return()`.
```c // Inside bpf_xdp_adjust_tail() or its helper path for ZC:
if (unlikely(xdp->rxq && xdp->rxq->zsk)) {
struct xsk_buff_pool *pool = xdp->rxq->zsk; // If the adjustment causes a fragment to be effectively removed // or modified in a way that breaks ZC tracking, we must update the list. // Example: If tail is moved such that a previous frag node is no longer valid/needed if (needs_frag_removal) {
xsk_buff_remove_frag_node(xdp, page_ptr); } }
// Then proceed with normal XDP return logic __xdp_return(xdp); // Now safe because ZC state is consistent ```
#### 3. Ensure `ice_clean_rx_irq_zc` Uses Correct Return Path
The driver's NAPI poll function must ensure that when it calls back into the BPF program (which might call `bpf_xdp_adjust_tail()`), any resulting changes to buffer ownership are correctly reflected in the ZC pool before returning buffers to the hardware.
### Key Takeaways for Debugging/Verification
1. **Reproduce**: Try triggering an XDP program that calls `bpf_xdp
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.