On June 2024, a new vulnerability was disclosed and fixed in the Linux kernel's tracing subsystem, tracked as CVE-2024-50132. This bug, though technical, could have serious implications for system stability and possibly security, especially in environments with custom or untrusted tracing probes. In this long-read post, we'll break down what happened, how the bug occurred, and why the patch that fixed it matters. We’ll include example code, references, and explain potential exploitation for learners and sysadmins alike.

What’s the Problem? (The TL;DR)

The trace_probe functionality in Linux lets you create dynamic probes for tracing kernel functions. When people (or programs) set up a probe with too many arguments (fetchargs), the kernel would set the number of arguments before actually checking if it exceeded the hardcoded MAX_TRACE_ARGS (128). But it would only initialize up to that limit, leading to the kernel having an invalid pointer to an argument slot that didn’t exist.

Trying to access this "phantom" slot led to this scary looking kernel error

BUG: kernel NULL pointer dereference, address: 000000000000002
#PF: supervisor read access in kernel mode
Oops: Oops: 000 [#1] PREEMPT SMP PTI
CPU:  PID: 1769 Comm: cat Not tainted 6.11.-rc7+ #8
RIP: 001:__set_print_fmt+x134/x330

This could crash your kernel, and while it's not a direct privilege escalation, it's a stability problem (and maybe an attack vector if the tracing interface is exposed).

Here’s a simplified snippet reflective of the buggy logic pre-fix

// MAX_TRACE_ARGS is 128
tp->nr_args = n_args;  // n_args could be >128

// Only initialize (or allocate) up to MAX_TRACE_ARGS
for (i = ; i < MAX_TRACE_ARGS && i < n_args; i++) {
    tp->args[i] = some_init();
}

// Later, code trusts tp->nr_args
for (i = ; i < tp->nr_args; i++) {
    do_stuff_with(tp->args[i]);  // Uh oh! args[128] might not exist
}

So, if n_args was 200, only args ..127 got initialized, but the code would assume up to 199 existed and try to use them.

Why Is This Bad?

If a local attacker (or even an admin making a mistake) tries to create a probe with more than 128 arguments, the kernel would try to access memory outside the bounds of what was allocated. This leads to a Null Pointer Dereference (often a hard crash), which is both a Denial of Service (DoS), and possibly a vector for kernel exploitation under special conditions (if code paths can be manipulated).

If you run tracing infrastructure affected by this bug and allow users to define custom probes, you MUST update.

The Fix

The fix is straightforward: before setting nr_args, check if the limit is being exceeded. If so, reject the probe request entirely with an error, rather than silently truncating.

Patched Logic (as of Linux 6.11 rc8+)

if (n_args > MAX_TRACE_ARGS) {
    return -EINVAL;  // Too many fetch args, error out earlier
}

tp->nr_args = n_args;
// Initialize as before...

Commit Reference:
- kernel/git/torvalds/linux.git – tracing: Fix MAX_TRACE_ARGS limit handling

Proof of Concept Exploit

Here’s an example of how you would crash a vulnerable kernel as root (Don’t do this on production!):

# create-probe.sh
echo 'p:myprobe some_function arg1=%rdi arg2=%rsi ... arg129=%r8' > /sys/kernel/debug/tracing/kprobe_events

(*you’d have to repeat the argument line to go above 128 args*)

On a vulnerable kernel, this will cause an Oops/panic. On a patched kernel, you’ll get

write error: Invalid argument

and the probe won’t be installed.

Security Impact

While exploiting this for privilege escalation is non-trivial (you must be able to insert kprobes, which is a privileged operation by default), causing a Denial of Service (kernel panic/crash) is trivial for any attacker with that ability.

If you run container systems, debugging environments, or allow device or edge users to configure tracing, this vulnerability may be critical for you.

Kernel Version: If you are running Linux before 6.11-rc8, you are likely vulnerable.

2. Test: Try installing a kprobe with more than 128 args as shown above. If you get a kernel crash — you’re vulnerable!

Never allow untrusted users to set probes.

- Restrict access to /sys/kernel/debug/tracing/kprobe_events.

References

- Linux Kernel Patch Commit
- CVE-2024-50132 at NVD *(pending as of this writing)*
- Kernel Tracing Documentation
- LKML Discussion

Conclusion

CVE-2024-50132 is a great example of how seemingly small boundary bugs in kernel code can lead to big problems. Always validate user inputs —even in internal kernel code— and be mindful of hardcoded limits. If you rely on Linux's tracing subsystem, patch now, or risk a possible system crash.

Timeline

Published on: 11/05/2024 18:15:15 UTC
Last modified on: 11/07/2024 21:32:37 UTC