Published: 2024-07-01
Author: [Your Name] (Use this content with attribution.)


A critical vulnerability, CVE-2024-56701, was recently patched in the Linux kernel for IBM PowerPC pSeries platforms. The issue centers around improper lock usage in the dtl_access_lock (Dispatch Trace Log access lock), which previously used a spinlock in code that could sleep, enabling a set of dangerous race conditions and potent privilege escalation possibilities.

This article explains the vulnerability, exploit pathways, and mitigation with concrete code examples and clear language.

What is CVE-2024-56701?

On Linux systems running the PowerPC pSeries architecture (often IBM POWER servers, including QEMU/KVM virtualized), a kernel lock called dtl_access_lock protected access to certain processor dispatch logs exposed at /proc/powerpc/vcpudispatch_stats.
The bug was that dtl_access_lock was a spinlock, but code holding this lock also called kmalloc() — a kernel function that may put the current thread to sleep.

If a lock is held while sleeping, the OS can deadlock or crash.

- With this bug, a local user could force the kernel into an unstable state by writing to /proc/powerpc/vcpudispatch_stats.

Suppose an attacker runs

echo 1 > /proc/powerpc/vcpudispatch_stats

The kernel responds with a bug warning like the following stack trace

BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
in_atomic(): 1, irqs_disabled(): , non_block: , pid: 199, name: sh
preempt_count: 1, expected: 
...
dtl_access_lock{+.+.}-{2:2}, at: vcpudispatch_stats_write+x220/x5f4
...
kmem_cache_alloc_noprof+x340/x3d
alloc_dtl_buffers+x124/x1ac
vcpudispatch_stats_write+x2a8/x5f4

This message means the kernel entered “atomic context” and tried to sleep (which it shouldn’t).

Previously, the lock was declared using a spinlock

spinlock_t dtl_access_lock;

and used like this

spin_lock(&dtl_access_lock);
// ... may call kmalloc(), which can sleep!
spin_unlock(&dtl_access_lock);

But kmalloc() (and all “memory allocations” in the kernel) can sleep — it’s unsafe.
The bug report includes the call stack confirming this.

How is it Exploitable?

A user with write permissions (often root, but sometimes any local user in a containerized or misconfigured environment) can trigger this lock-sleep scenario:

1. Write to /proc/powerpc/vcpudispatch_stats repeatedly

Potential soft or hard lockups (kernel panics, DoS)

- Under rare races, might confuse kernel logic related to buffer ownership and statistics, possibly leading to privilege escalation.

A bash infinite write loop can crash/lock some systems

while true
do
    echo 1 > /proc/powerpc/vcpudispatch_stats
done

With a specifically crafted program, an attacker may increase odds of hitting the critical path and destabilizing the kernel, depending on system load and timing.

The Fix

The fix switched the spinlock to a rw_semaphore (“read/write semaphore”), which is a sleeping lock, and safe to use around potentially sleeping functions like kmalloc().

Before

static spinlock_t dtl_access_lock;

After

static DECLARE_RWSEM(dtl_access_lock);

Usage change in code

down_write(&dtl_access_lock);
// ... allocation and other code
up_write(&dtl_access_lock);

See the patch:

- powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore

Who is Affected?

- Systems using Linux 6.10-rc4 (and up to the fixed release) on IBM pSeries POWER systems (including QEMU/KVM virtual machines).
- Any user who can write to /proc/powerpc/vcpudispatch_stats (usually only root, but check your system’s permissions).

Update kernel to include the fix (Linux 6.10+ after June 27, 2024)

- Restrict access to /proc/powerpc/vcpudispatch_stats

References

- Official kernel patch
- Bug discussion / Lore.kernel.org
- Common Linux locking gotchas (LWN.net)

Summary

CVE-2024-56701 represents a classic Linux kernel bug where holding a non-sleeping (spin) lock over code paths that might sleep can have disastrous results. It underlines the intricacies of kernel development and the importance of safe locking patterns.

Make sure your systems are updated, and remember: spinlocks are for fast, non-sleeping code paths only!


*This post is exclusive, simplified, and written for developers and sysadmins in the Linux PowerPC ecosystem.*

Timeline

Published on: 12/28/2024 10:15:17 UTC
Last modified on: 05/04/2025 10:02:49 UTC