In early 2024, a significant vulnerability was discovered and patched in the Linux kernel, specifically affecting the s390 architecture and its Direct Access Storage Device (DASD) subsystem. This vulnerability, tracked as CVE-2024-27054, might sound obscure, but it reveals how a small coding oversight can destabilize an entire system.

If you’re interested in kernel-level security, exploit development, or just want to understand why these little reference counters matter so much, you’re in the right place. We’ll walk through the bug, show you the code, explain the issue in plain English, and outline the exploit scenario.


## What is s390/dasd?

The s390 is IBM's architecture for mainframes; the DASD driver handles block storage devices on these systems. Moduleref counting helps Linux keep track of how many users (or kernel components) are using a particular module, preventing it from being unloaded while in use.

What’s The Problem? (The Vulnerability)

When a DASD device is added and its "discipline" (kind of like a driver handler) is associated, the kernel holds a refcount (reference count) on the module for as long as it’s in use. If the association fails, the code tried to decrement the count manually on the error path. However, once the discipline is associated, deleting the device *already* takes care of that. So, manually decrementing the counter would lower the refcount twice on each error—that’s called a "double decrement."

The Impact

Decrementing module reference counts erroneously can lead to use-after-free bugs or allow an attacker to forcibly unload (“rmmod”) a module that is technically still in use. This is a classic way to destabilize or take over a Linux system.

The Code (The Bug & The Fix)

Let’s see a simplified code snippet showing the buggy and patched logic.

Vulnerable (pre-patch):

if (associate_discipline(dev) != ) {
    module_put(discipline->owner);   // <-- Problem: double decrement occurs
    goto out;
}
...
out:
   // cleanup

Patched (fixed):

if (associate_discipline(dev) != ) {
    goto out;   // Don't decrement here, it's handled elsewhere
}

Reference:
- Upstream kernel patch commit (view raw patch)

How Might an Attacker Exploit This?

To exploit CVE-2024-27054, an attacker would need *some* ability to trigger errors during the discipline association phase of DASD device initialization. This isn't usually accessible to common users, but if you have that control—perhaps as a container admin or with certain device access privileges—here's what could happen:

1. Deliberately cause association failures: Repeatedly trigger them to force the kernel module refcount to drop.
2. Premature Module Unload: When the refcount hits zero, the module can be unloaded even if still in use, potentially crashing the system or making kernel memory available for re-use (leading to dangerous "use-after-free" scenarios).
3. Privilege Escalation/Denial of Service: In the worst-case, carefully orchestrated exploitation could lead to privilege escalation or just render the system unstable.

Proof-of-Concept Scenario

You'd have to be on a system using DASD and have some access to device management. In practice, a malicious admin script could look like this (pseudocode):

for i in {1..100}
do
   # Trigger a device with bad configuration to fail association
   echo "bad_disciplined_device" > /sys/bus/ccw/drivers/dasd-eckd/new_id
   # Immediately remove the device to force cleanup
   echo <device_id> > /sys/bus/ccw/drivers/dasd-eckd/remove_id
done

# Now, the refcount could be dropped and allow e.g., "rmmod dasd_mod"

*Note: Actual device manipulation requires root access and is hardware/driver specific.*

How Was The Issue Fixed?

The core fix was simple: don’t mess with the refcount manually, let the rest of the kernel handle it. The patch removed the manual module_put() in the error path.

Are You Vulnerable?

- This bug only affects Linux systems running on the IBM s390 platform with the DASD driver. Most desktop or server users aren’t affected.

References and Further Reading

- The Linux Kernel CVE Tracker
- Linux kernel patch commit
- Linux s390 DASD driver documentation

Conclusion

CVE-2024-27054 is a great example of how reference counting—one of the oldest tricks in the book for resource management—matters for security. While not easy to exploit in most environments, the implications on mainframe systems could be huge, especially in multi-tenant environments or with overly permissive admins.

If you work on or with s390 Linux, patch up now!

*Did this post help you? Need more hands-on kernel security analysis in simple language? Let me know!*

Timeline

Published on: 05/01/2024 13:15:50 UTC
Last modified on: 11/06/2024 20:35:11 UTC