CVE-2024-45002 - Linux Kernel rtla/osnoise NULL Pointer Dereference Vulnerability Explained

In May 2024, a new vulnerability known as CVE-2024-45002 was identified and patched in the Linux kernel's rtla/osnoise tool. This is a highly technical issue, but with real-world stability impacts for users of the tool. If you use the Linux kernel for real-time analysis, or if you run tools that depend on it, this long read will help you understand what happened, why it matters, and how to recognize and mitigate the risk, including code examples and direct references.

## What is rtla/osnoise?

The rtla (Real-Time Linux Analysis) suite in the Linux kernel includes several utilities; osnoise is one of them. osnoise is designed to analyze operating system noise — that is, interruptions that could affect real-time workloads.

Summary

The vulnerability occurs during memory allocation for an internal data structure (tool->data). If this allocation fails (due to low memory, for instance), the code tried to free resources that were never successfully allocated. Specifically, it called osnoise_free_top() when there was nothing to free, leading to a NULL pointer dereference. That means the kernel tries to access memory at address zero… which always leads to a crash.

Here’s a simplified version of the risky code

tool->data = malloc(data_size);
if (!tool->data) {
    osnoise_free_top(osc); // Problem: tool-&gt;data is NULL, nothing to free!
    return -ENOMEM;
}

If malloc fails, tool->data is set to NULL, but the code still calls the cleanup function, which tries to dereference that NULL pointer.

The Fix

The correct way is: Don’t attempt to free if there’s nothing to free. The patch adds a check to skip the cleanup call if tool->data is NULL.

Code Snippet After Patch

tool->data = malloc(data_size);
if (!tool->data) {
    // Don't call osnoise_free_top() here!
    return -ENOMEM;
}

This avoids any attempt to dereference a NULL pointer.

Reference to the fix commit:
LKML commit - osnoise: Prevent NULL dereference in error handling
Relevant discussion:
https://lore.kernel.org/lkml/20240520090504.586487-1-joro@8bytes.org/

Is This Remotely Exploitable?

No; this is not a remote exploit. Only local users (those with the ability to run rtla osnoise commands) could potentially trigger the bug, and only if you’re running an affected version of the Linux kernel.

How Might Attackers Abuse This?

- Denial of Service (DoS): By purposefully setting up the system to exhaust memory, an attacker could cause tool->data allocation to fail, and then trigger the vulnerable cleanup logic, causing the kernel to crash with a NULL pointer dereference (kernel oops/panic).
- Unstable System: In real-time systems, a sudden kernel stop can mean service downtime, especially for robotic, financial, or embedded platforms.

Example Proof-of-Concept Trigger

While not a remote code execution, if you run the following as a low-privileged user on a vulnerable kernel where you can launch rtla osnoise, you could cause a kernel crash.

# Artificially eat up memory (dangerous, do not run as root on production!)
stress --vm 2 --vm-bytes 95% --timeout 10s

# In another terminal, try to run:
rtla osnoise top

If the malloc inside the tool fails due to low memory, before the patch, the kernel could crash.

Mitigation

- Apply the patch: Use a kernel version including (or newer than) commit 53205d6ce7086c2562564bed11b3fb405e805dc8.

You can check your kernel version with

uname -r

If your kernel is older than the above commit date (May 2024), check your distribution’s advisories.

Conclusion

CVE-2024-45002 is a classic example of error handling gone wrong: even small checks matter in kernel code, because the stakes are high. Although not a remote exploit or privilege escalation, it’s a potential DoS issue. Patch your kernels, take care with who can run diagnostic tools, and, as always, pay attention to the detailed kernel changelogs!

Timeline

Published on: 09/04/2024 20:15:08 UTC
Last modified on: 09/06/2024 16:27:13 UTC