CVE-2024-57939 - A Deep Dive Into the RISC-V Linux Kernel die() Sleeping Bug (And How It Was Fixed)

Summary:
A recent vulnerability in the Linux kernel, impacting RISC-V systems running with PREEMPT_RT (Real-Time Preemption), could potentially lead to sleeping in an invalid context in the die() function—a scenario that should never occur in kernel exception handling. Dubbed CVE-2024-57939, this bug is subtle, technical, and important for anyone deploying Linux on RISC-V with real-time patches.

In this post, we’ll break down what happened, why it’s important, the fix in plain English, provide key code snippets, and share exploit scenario details. By the end, you’ll understand what caused the panic, why die() shouldn’t sleep, and how the kernel community fixed this low-level but crucial bug.

What is CVE-2024-57939?

CVE-2024-57939 refers to a vulnerability specific to the Linux kernel’s die() function on RISC-V architectures, especially when running with the PREEMPT_RT configuration enabled. The main problem? The die() function could—under exceptional system errors—try to acquire a regular spinlock (spinlock_t) that may go to sleep, but sleeping is forbidden in certain kernel contexts (like exception handlers).

The bug can produce this kernel warning

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: , pid: 285, name: mutex
...
die+x24/x112
do_trap_insn_illegal+xa/xea
Oops - illegal instruction [#1]

Why Is Sleeping in die() a Problem?

The die() function is called when something has gone _wrong_ in the kernel: typically, after a CPU exception or illegal instruction. At this moment, the kernel is in a very sensitive state—it might be holding locks, have interrupts disabled, or be running in an atomic context.

Sleeping (for example, waiting for a lock) is dangerous here, since it will deadlock or hang the system. Kernel code in such contexts must NEVER sleep. However, on systems built with PREEMPT_RT, some locking primitives like spinlock_t can sleep.

On certain RISC-V kernels, die() used a spinlock_t, which—on RT kernels—turns into a regular mutex that can sleep! So, in a panic, die() could try to acquire a lock, but end up sleeping, causing a "BUG" and a system crash.

The Fix: Use raw_spinlock_t

The necessary fix is to switch locking inside die() from a potentially-sleeping spinlock_t to a raw_spinlock_t—a true spinlock that will never, ever sleep, not even in a PREEMPT_RT kernel.

The Key Patch (Code Snippet)

Here’s an excerpt adapted from the official patch commit:

-static DEFINE_SPINLOCK(die_lock);
+static DEFINE_RAW_SPINLOCK(die_lock);

And inside the die() function

-    spin_lock_irqsave(&die_lock, flags);
+    raw_spin_lock_irqsave(&die_lock, flags);
     ... // critical section
-    spin_unlock_irqrestore(&die_lock, flags);
+    raw_spin_unlock_irqrestore(&die_lock, flags);

By using raw_spinlock_t and its corresponding lock/unlock API, the kernel ensures the lock will not sleep, preventing the panic and associated "invalid context" warnings.

Exploit Scenario and Impact

While not an _exploit_ in the classic sense, this bug can lead to denial of service: an attacker or process that manages to trigger an illegal instruction or exception on a PREEMPT_RT-enabled RISC-V kernel could cause the kernel to hit this "sleep in invalid context" BUG and bring down the system.

Userspace or driver code (with high privileges) misusing hardware functionality.

In production real-time RISC-V systems, this could mean total loss of system responsiveness until reset or powercycle.

Have the PREEMPT_RT patchset enabled.

To fix:
Update to a kernel after the mainline commit b034b08f86d13928dbedecbe68e930dc83860467, or backport this single locking change.

References and Further Reading

- Upstream Linux patch
- PREEMPT_RT and Real-Time Linux project
- Linux RISC-V Port Overview
- CVE Details Page (when available)

Conclusion

CVE-2024-57939 is a clear example of how subtle kernel locking details, platform support, and real-time patches can collide to create surprising bugs that only show up in very unusual configurations. Thanks to quick action from the Linux kernel community, the risk was caught and squashed early.

Takeaway: _If you are running real-time Linux on RISC-V, patch up now._ Keep an eye on strange kernel crashes involving locking during exceptions—they’re never benign!


*Want more kernel deep-dives and vulnerability breakdowns? Follow for more exclusive, plain-English security breakdowns!*

Timeline

Published on: 01/21/2025 13:15:07 UTC
Last modified on: 02/28/2025 18:58:55 UTC