CVE-2024-56768 - Serious Bug in Linux Kernel’s bpf_get_smp_processor_id() Exposed—Here’s What You Need to Know

A recently resolved vulnerability in the Linux kernel, identified as CVE-2024-56768, could crash machines or potentially open up attack vectors in specific setups. It relates to the eBPF (extended Berkeley Packet Filter) subsystem and specifically how processor IDs are fetched on certain builds. If you’re a kernel developer, distro maintainer, or a sysadmin running custom Linux builds, this one’s for you.

What’s the Problem?

The bug lurks in the bpf_get_smp_processor_id() helper, which is used in eBPF programs to fetch the current processor’s identifier. On systems where the kernel is compiled WITHOUT SMP support (meaning no Symmetric Multi-Processing, usually small embedded or single-core systems), a missing check could cause the kernel to crash with a page fault.

Here’s the real kicker:
If your kernel is built without CONFIG_SMP, calling this helper will access memory it’s not supposed to—because the per-CPU hot variable it expects simply doesn’t exist. That leads straight to a kernel panic.

This is exactly what you’d see in your boot logs

[    8.471774] BUG: unable to handle page fault for address: 00000000936a290c
[    8.471849] #PF: supervisor read access in kernel mode
[    8.471881] #PF: error_code(x000) - not-present page

This means the kernel tried to read from a not-present memory page while running in supervisor (kernel) mode. The aftermath? A system crash.

Why Did This Happen?

The problem lies in a missing conditional compilation logic. Normally, the code to fetch the CPU ID is only valid when SMP is enabled, i.e., multicore kernels. With CONFIG_SMP off, that logic shouldn’t be used; instead, the only valid CPU ID is —since you only have a single processor.

Here’s the problematic path in the code (simplified for clarity)

int bpf_get_smp_processor_id()
{
    // On SMP kernels, this reads a per-CPU hot variable
    return raw_smp_processor_id();
}

But raw_smp_processor_id() relies on data only present in SMP kernels.

Solution: Quick and Simple

The kernel patch simply makes bpf_get_smp_processor_id() always return on non-SMP builds. Here is roughly how the fix goes:

#if defined(CONFIG_SMP)
int bpf_get_smp_processor_id(void)
{
    return raw_smp_processor_id();
}
#else
int bpf_get_smp_processor_id(void)
{
    return ;
}
#endif

Reference:
Linux kernel commit fixing CVE-2024-56768

How Could Someone Exploit This?

While this bug does not directly allow code execution or privilege escalation, a regular (privileged) user with eBPF access (which is increasingly locked down on most distros by default) could write a program to intentionally crash the system:

Example of a malicious eBPF program

SEC("xdp_prog")
int crash_kernel(struct xdp_md *ctx) {
    int cpu = bpf_get_smp_processor_id(); // <--- Triggers crash on vulnerable kernel
    return XDP_PASS;
}

Loaded through any eBPF-capable mechanism, this would immediately cause a kernel panic on a uni-processor build.

Mostly custom Linux builds or embedded devices that disable SMP (CONFIG_SMP=n).

- Big distros (Ubuntu, Fedora, Debian, etc.) always build with SMP enabled, so desktop/server users are generally safe.
- If you build your own kernel for single-board or embedded systems, you must check for this patch.

Double-check kernel config to see if CONFIG_SMP is off.

Patch reference:
- Upstream commit
- Kernel bug tracker entry

Bottom Line

CVE-2024-56768 is a classic “corner case” bug that only crops up in rare setups. But if you run those setups, it’s a real headache—crashing your kernel with just one BPF call. Now fixed, it’s a reminder to always pay attention to different build configurations and their impact on kernel helpers.

Timeline

Published on: 01/06/2025 17:15:43 UTC
Last modified on: 01/07/2025 22:50:43 UTC