CVE-2024-50133 - Linux Kernel LoongArch Crash – stack

A new Linux kernel vulnerability, CVE-2024-50133, was quietly patched in the LoongArch architecture code. This bug can cause crashes in certain situations, especially for kernel threads (kthreads) interacting with memory layout code. The fix prevents an ugly kernel crash when a non-user task, like a kthread, lacks a vDSO (virtual Dynamic Shared Object) and tries to access its stack top.

In this post, we’ll break down the bug in simple terms, show where it lives in the code, explain how it’s triggered (with practical insights) and why it could matter for system stability or even exploitation.

What is vDSO and Why Does This Matter?

The vDSO is a small, kernel-provided library mapped into user processes to accelerate certain system calls. Not all processes get a vDSO. In particular, kernel threads (kthreads) never do. Trying to access information about a vDSO for a kthread yields a NULL pointer.

Here’s the sketch of the relevant logic in the Linux kernel (as seen before the fix)

unsigned long stack_top(struct mm_struct *mm)
{
    // LoongArch arch code (before fix)
    return (unsigned long)mm->context.vdso + PAGE_SIZE;
}

If mm->context.vdso is NULL (i.e., ), this will try to dereference address x + PAGE_SIZE = x100—which blows up.

Real Trace of the Crash

This is the backtrace you’ll see if the bug is triggered in a LoongArch kernel with something like kunit (the kernel test harness):

[<9000000000203874>] stack_top+x58/xa8
[<90000000002956cc>] arch_pick_mmap_layout+x164/x220
[<90000000003c284c>] kunit_vm_mmap_init+x108/x12c
[<90000000003c1fbc>] __kunit_add_resource+x38/x8c
[<90000000003c2704>] kunit_vm_mmap+x88/xc8
[<900000000041b14>] usercopy_test_init+xbc/x25c
[<90000000003c1db4>] kunit_try_run_case+x5c/x184
[<90000000003c3d54>] kunit_generic_run_threadfn_adapter+x24/x48
[<900000000022e4bc>] kthread+xc8/xd4
[<900000000020ce8>] ret_from_kernel_thread+xc/xa4

It starts in stack_top, which dies when it encounters a kernel thread without a vDSO.

Exploitation Scenario

This is primarily a stability and DoS (Denial of Service) issue. By triggering code that assumes a vDSO exists on kernel threads—often in kernel debugging or test code—you can crash the kernel. A local user able to trigger kunit/unit-test or similar functionality could panic the system.

While not a straightforward privilege escalation, any kernel panic is a risk, especially on production or critical systems, and could potentially be used for more attacks in combination.

The Simple Fix

The kernel patch simply adds a check for a NULL vdso pointer before using it. Here’s how to fix it (simplified):

// After the fix:
unsigned long stack_top(struct mm_struct *mm)
{
    if (!mm->context.vdso)
        return ;       // Or handle error gracefully
    return (unsigned long)mm->context.vdso + PAGE_SIZE;
}

If there’s no vDSO, stack_top() returns or handles gracefully, preventing a null dereference.

Most mainstream Linux distributions are NOT affected unless you use LoongArch hardware.

To check if your kernel has the fix, search for this commit or equivalent in your kernel source tree:

- Upstream Linux Fix (commit to LoongArch)

## Proof-of-Concept / Trigger

If you test kernel code like kunit on LoongArch with the unfixed kernel, and run mmap-related or usercopy tests, you will likely hit the crash. It is not exploitable directly from userland without special privileges, but it's very easy to trigger for developers and test setups.

Example code that can trigger the bug (pseudo)

// This runs in kernel-space, simulating what kunit does
void test_kthread_stack_top(void)
{
    struct mm_struct *kernel_mm = current->mm;
    unsigned long top = stack_top(kernel_mm);
    printk("Stack top is: x%lx\n", top);
    // This will crash if kernel_mm->context.vdso == NULL
}

References

- Linux Kernel Patch - LoongArch: Don't crash in stack_top() for tasks without vDSO
- LoongArch Architecture Information
- KUnit: Linux Kernel Unit Testing Framework
- CVE Details page for CVE-2024-50133 (when available)

TL;DR

If you run Linux on LoongArch, update your kernel to avoid crashes in rare kthread–memory interactions. This will harden your system against a simple—but nasty—bug that previously could panic your system through tests or debugging routines.

*This post is summarized, explained, and demonstrated exclusively for accessibility and clarity. For full technical details, check the referenced patch and upstream documentation!*

Timeline

Published on: 11/05/2024 18:15:16 UTC
Last modified on: 11/07/2024 21:17:35 UTC