CVE-2024-26611 is a high-impact vulnerability affecting the Linux kernel's XDP (eXpress Data Path) support for AF_XDP sockets, specifically when multi-buffer BPF helpers are used with Zero Copy (ZC) memory type.

This issue allows an attacker to trigger a kernel NULL pointer dereference via the bpf_xdp_adjust_tail() helper when used with MEM_TYPE_XSK_BUFF_POOL, resulting in a total system crash (kernel panic).

Technical Summary

When user-space applications (like high-performance network daemons) utilize AF_XDP sockets with ZC enabled and make use of multi-buffer XDP helpers, if a packet is "shrunk" (i.e., tail trimmed) via bpf_xdp_adjust_tail(), an internal XDP pointer operation is wrong, leading to a NULL dereference in the kernel. This means unprivileged local code can kernel panic your box (DoS situation).

Sample kernel log

BUG: kernel NULL pointer dereference, address: 0000000000000034
#PF: supervisor read access in kernel mode
...
RIP: 001:__xdp_return+x6c/x210
...
bpf_xdp_adjust_tail+x155/x1d
bpf_prog_xdp_sock_prog+x15/x60
ice_clean_rx_irq_zc+x206/xc60 [ice]
ice_napi_poll+x467/x670 [ice]
...

The XDP code is designed to manipulate network buffers at very high performance rates.

- When an XDP program shrinks a buffer with bpf_xdp_adjust_tail() and the buffer is coming from the AF_XDP ZC pool (MEM_TYPE_XSK_BUFF_POOL), the driver maintains a list called xskb_list of all the fragments/buffers.
- The AF_XDP subsystem expects to remove the right element (fragment) from that list when buffers are consumed or released.
- The BPF helper, however, mishandles this list in the ZC case, and invalidly returns a NULL buffer pointer to __xdp_return().

Error scenario in code

struct xdp_buff *xdp = get_next_xdp_buff(...);
if (xdp_should_be_removed)
    xdp = NULL; // incorrectly set!
__xdp_return(xdp);  // dereferenced inside --> KERNEL PANIC!

Correct handling (from the patch)

The fix ensures that instead of passing NULL, the correct fragment/node is always located and pulled out safely from the list before xdp_buff* is dereferenced.

Exploit Details and Reproduction

While this is not a "remote" or "privilege escalation" exploit, any user with local, unprivileged access to an AF_XDP socket and permission to load BPF/XDP programs (CAP_NET_ADMIN) can trivially crash the machine. Exploiting this vulnerability does not require elaborate steps; it is essentially a logic error in buffer handling.

BPF Program Example

A minimalist proof-of-concept BPF XDP program that triggers the bug could look like this (in user-friendly pseudocode):

SEC("xdp_sock_prog")
int xdp_sock_prog_func(struct xdp_md *ctx) {
    // The bug is triggered if this returns non-zero on a ZC AF_XDP pool buffer
    bpf_xdp_adjust_tail(ctx, -64); // shrink last 64 bytes
    return XDP_PASS; // continue processing
}

Reproduction Steps

1. Setup an AF_XDP socket with XDP_ZEROCOPY enabled (using tools like xdpsock or any high-perf datapath code).

The problem is fixed in upstream kernels by a commit that

- Ensures on buffer shrink/delete, the correct node is found/removed from xskb_list via proper AF_XDP/ZC-aware helpers.

Never passes a NULL xdp_buff* to __xdp_return().

Relevant commit:
- bpf, xsk: fix usage of multi-buffer BPF helpers for ZC XDP
- CVE record at NVD

Official kernel inclusion:

Mitigation

- Patch immediately: If you use AF_XDP with ZC (often in cloud, edge, or performance networking setups), update to a kernel with the fix.

Linux kernel commit:

bpf, xsk: fix usage of multi-buffer BPF helpers for ZC XDP
- CVE-2024-26611 at NIST NVD
- Patch Discussion

Summary

CVE-2024-26611 is a kernel crash bug, trivial to trigger for anyone using AF_XDP ZC sockets and XDP BPF helpers that manipulate buffer size. The bug has been fixed upstream—all users of AF_XDP and XDP should upgrade immediately.


*If you found this post helpful, bookmark or share with your Security/DevOps team. Stay safe and keep your kernels updated!*

Timeline

Published on: 03/11/2024 18:15:19 UTC
Last modified on: 12/12/2024 15:30:50 UTC