> Summary:
Earlier this year, a vulnerability in the Linux Kernel’s cryptographic subsystem—specifically in the pcrypt module—was registered as CVE-2024-56690. This post will walk you through the nature of this bug, the subtle implications for kernel stability and system security, and the specific patch that resolved it. We’ll look at the code changes, explain why the panic happened, and why this vulnerability is less about direct exploitation—and more about creating denial-of-service scenarios.

Background: What is pcrypt?

The pcrypt module in Linux’s crypto API provides parallel cryptographic transformations. This lets the kernel efficiently handle encryption and decryption on multi-core systems, but adds complexity due to parallel state and kernel scheduler interactions.

Where it happened

The bug appeared after commit 8f4f68e788c3 (crypto: pcrypt - Fix hungtask for PADATA_RESET). Since then, when the kernel CPUs go online or offline, pcrypt could return -EAGAIN for encryption or decryption calls (e.g. pcrypt_aead_encrypt).

Typically, userspace (or kernel code) is expected to handle this by retrying the cryptographic operation. But in the context of alg_test() (crypto self-tests at boot), receiving an -EAGAIN triggers a WARN. And if your system is set with panic_on_warn=1 (a reasonable paranoia setting in some hardened environments), your whole kernel will panic and reboot!

> *Unnecessary kernel panics are as harmful as actual vulnerabilities—turning reliability into fragility.*

Fix summary

The fix ensures that if padata_do_parallel() returns -EBUSY, instead of bubbling up an error (which is interpreted as a crypto malfunction), the encryption is tried using the serial (non-parallel) code path. This avoids triggering a WARN, skips unnecessary panics, and gives the expected crypto result.

Before: Vulnerable pcrypt code

static int pcrypt_aead_encrypt(struct aead_request *req)
{
    ...
    err = padata_do_parallel(padata, ps, req);
    if (err) {
        return err;   // -EBUSY bubbles up, -EAGAIN returned.
    }
    ...
}

After: Patched version

static int pcrypt_aead_encrypt(struct aead_request *req)
{
    ...
    err = padata_do_parallel(padata, ps, req);
    if (err == -EBUSY) {
        // Fallback: call the crypto layer directly, bypassing pcrypt parallel path
        return crypto_aead_encrypt(cryptd_child, req);
    } else if (err) {
        return err;
    }
    ...
}

Key idea: Instead of letting -EBUSY cause warnings, immediately do the work serially and move on. This decision makes boot-time crypto tests (and other callers) robust—no more surprise panics if you’re flipping CPUs.

*See original fix at this kernel commit.*

Denial-of-Service? *Yes, in certain configs.*

Malicious userspace (or kernel modules) could intentionally call into the pcrypt API, arrange for CPU hotplug activity (like scripting CPU on/off cycles), and flood the crypto API, causing repeated -EAGAIN. On systems with panic_on_warn=1, each WARN could force a kernel panic, potentially leading to repeated reboots (denial of service).

Here’s a *theoretical exploit* (expressed in pseudo-C) using /sys hotplug and AF_ALG crypto sockets:

// pseudocode: as root via AF_ALG and CPU offline/online hotplug
while (1) {
    // Off/on cores
    system("echo  > /sys/devices/system/cpu/cpu3/online");
    system("echo 1 > /sys/devices/system/cpu/cpu3/online");
    // Flood with crypto requests
    int fd = socket(AF_ALG, SOCK_SEQPACKET, );
    // send bogus data to trigger pcrypt paths
    // check for failed -EAGAIN;
    close(fd);
    // trigger alg_test for new modules (could call insmod/rmmod loop)
}

On such a system with panic_on_warn=1, this loop could cause cascading panics.

References

- NVD CVE-2024-56690 Entry
- Linux Kernel Patch Commit (direct link)
- Relevant kernel discussion thread
- Linux crypto API documentation

Conclusion

While CVE-2024-56690 isn’t your classic remote code execution or kernel privilege escalation bug, it highlights the importance of defensive programming in kernel interfaces, especially where experimental system states (like CPU hotplug) cross with security-critical code (crypto and panic-on-warn). In this way, tiny errors become huge liabilities under the wrong settings.

*Patch your kernels, guard your configs, and keep security simple!*


> *Want to read more in-depth Linux CVE breakdowns? Subscribe or follow for future kernel exploits, analysis, and real-world remediation tips!*

Timeline

Published on: 12/28/2024 10:15:13 UTC
Last modified on: 05/04/2025 13:01:14 UTC