CVE-2024-26957 was quietly patched in the Linux kernel, specifically in its s390/zcrypt subsystem. This vulnerability is a classic use-after-free bug that can be exploited when crypto cards are hot-plugged or hot-removed in s390 virtual machines (such as KVM guests).

Reference counters for zcrypt_card objects were incorrectly handled, allowing a card’s memory to be freed while still in use, leading to use-after-free and potential privilege escalation, information leakage, or kernel panic.
This long-read explains the bug, its real-world implications, and how one might approach exploitation.

What is zcrypt and Where’s the Bug?

The Linux zcrypt subsystem manages hardware crypto devices (hardware security modules, or cards) on IBM s390 and zSeries architecture. These cards may be dynamically added or removed, often in cloud environments.

In zcrypt, each card is represented by a struct zcrypt_card reference-counted object. If an object is freed (with kfree()) while still referenced, any future access corrupts memory and can be attacked by user-space actors.

The Problematic Sequence

When hot-plugging crypto cards, tests on KVM guests (virtual machines) running a debug kernel revealed this sequence:

Later code touches now-gone memory, creating a use-after-free (UAF) opportunity.

Here’s a snippet from the kernel log showing allocation and freeing traces (simplified, with comments):

Allocated in zcrypt_card_alloc   # Object is created (kmalloc)
...
Freed in zcrypt_card_put        # Object freed (kfree) - refcount drops to zero

Further down the call stack, some kernel code continues using this now-freed memory, possibly with attacker-controlled data or redirected kernel control flow!

Reference Counting 101

Reference counters (atomic_t, refcount_t, etc.) are the backbone of kernel object life management. If get() / put() are mispaired:

Excerpt from the Patch

The actual fix can be referenced in the official Linux kernel commit:

// Old code (simplified)
void zcrypt_card_put(struct zcrypt_card *card) {
    if (refcount_dec_and_test(&card->refcount))
        kfree(card);  // <-- UAF happens if something else holds a reference
}

The fix ensures each path holding a reference actually gets or puts it at the appropriate time, avoiding double-put or missing-get.

Who is affected?

- Any Linux kernel 6.x (before this patch) running on s390 with the zcrypt module loaded,

In a cloud setting, a virtualization attacker may

- Race the crypto card hot-unplug/removal sequence,

Trigger a use-after-free,

- Potentially gain arbitrary kernel read/write by reclaiming the freed slab with attacker-chosen data.

Sample Exploit Skeleton

Here’s a _theoretical_ sketch of how this bug could be poked, given sufficient privileges or I/O access:

// Pseudocode. Actual exploitation is _very_ hardware- and kernel-dependent.

trigger_zcrypt_card_hotplug();
trigger_zcrypt_card_hotremove();

// Rapidly spray kmalloc caches with your own objects:
for (int i = ; i < 10000; i++) {
    void *mem = kmalloc(SIZEOF_STRUCT_ZCRYPT_CARD, GFP_KERNEL);
    fill_with_payload(mem);
}

// ... attempt to cause code to access the freed zcrypt_card memory ...

If the kernel code accesses what it _thinks_ is a legitimate struct zcrypt_card, and you’ve filled it with controlled data, you might:

Real-World Feasibility

Actual exploitation is architecturally specific (s390, zSeries) and would require advanced kernel-fu, but the use-after-free is stark and present.

Mitigation & Fix

Upgrade immediately!
The fix landed in Linux mainline as of March 2024. Distributions with enterprise s390 workloads (SUSE, Red Hat, Ubuntu) have back-ported patches.

Mitigation tip:
- Avoid untrusted users being able to trigger card hot-plug/hot-remove events.

References and Further Reading

- Linux Kernel Patch Commit (kernel.org)
- SUSE Security Advisory
- Linux Crypto API (Docs)

Summary

CVE-2024-26957 is a critical use-after-free flaw in the zcrypt subsystem of the Linux kernel affecting s390 architectures. Left unpatched, attackers with the ability to manipulate crypto devices (even indirectly) could potentially seize kernel control via kernel memory corruption.

Upgrade. Always review hot-plug event handling. And keep your reference counters straight.

*This post is exclusive to this platform, and the original analysis is based on public code and commits. Use info responsibly. For questions, reach out!*

Timeline

Published on: 05/01/2024 06:15:11 UTC
Last modified on: 03/20/2025 21:27:17 UTC