Recently, a vulnerability was identified and fixed in the Linux kernel's Xilinx crypto engine code, tracked as CVE-2024-26877. This bug affects the way the crypto engine finalizes requests, potentially leading to kernel instability and unexpected behavior in environments leveraging Xilinx hardware cryptography, such as ZynqMP-based systems.

What is CVE-2024-26877?

Summary:
A race condition in the Linux kernel's support for Xilinx cryptographic hardware could trigger kernel warnings or panics if the software interrupts ("bottom halves," or BH) aren’t disabled while finalizing a crypto request.

Affected Component:
drivers/crypto/xilinx (but actually the bug revolves around correct use of the crypto_engine API)

Non-Technical Explanation

When the Linux kernel’s crypto subsystem wraps up a hardware crypto job, it must do so in a way that prevents other code from running at the same time and possibly breaking things. This is normally done by switching off certain kinds of interrupts just for a few moments—if you don’t, bad things can happen (like the scary stack trace shown below).

Here's a kernel warning triggered by this bug

------------[ cut here ]------------
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+xa/x118
...
Call trace:
 crypto_finalize_request+xa/x118
 crypto_finalize_aead_request+x18/x30
 zynqmp_handle_aes_req+xcc/x388
 crypto_pump_work+x168/x2d8
 kthread_worker_fn+xfc/x3a
 kthread+x118/x138
 ret_from_fork+x10/x20
---[ end trace 000000000000000 ]---

This shows the crypto engine’s crypto_finalize_request function being called without first disabling BH (Bottom Halves). That leads to possible race conditions and system instability.

Let's look at the relevant code. Here's an example of incorrect usage (vulnerable)

// BAD: finalize called with BH enabled
crypto_finalize_request(engine, req, err);

The correct usage is

unsigned long flags;
local_bh_disable();
crypto_finalize_request(engine, req, err);
local_bh_enable();

Or, better yet, use the kernel's dedicated helpers that guarantee the correct context.

What Actually Happened in the Code

The Xilinx driver called crypto_finalize_request() directly, without first disabling bottom halves. If this runs in a context where softIRQs are enabled, and another core/process preempts, this can (in rare timing cases) corrupt kernel data or allow hard-to-debug race conditions. That’s why the kernel developers ask for this to be done with BH disabled.

The Fix

See the patch (or similar relevant commit). Here’s the crux:

local_bh_disable();
crypto_finalize_request(engine, req, err);
local_bh_enable();

Kernel version: This bug was present up to 6.8.-rc1 (see the stack trace above).

2. Hardware: You need to be running on hardware using the Xilinx crypto engine (e.g., ZynqMP-based FPGAs like the ZCU102).
3. Distro: If you’re using a custom kernel or Yocto/poky build, check your kernel sources for the presence of the fix.
4. Logs: If you see the warning above in your dmesg/syslog, you’re definitely affected.

Exploit Details and Impact

- Privilege Required: Local kernel access (you must already be running code, like a kernel module, in the kernel)

Denial of Service: Kills crypto threads, can panic the kernel in rare cases

- Potential for Memory Corruption: Race conditions could, in theory, be abused for more serious attacks—though exploitation beyond DoS is not yet demonstrated.

Simple Exploit Scenario

Any user or process able to submit crypto jobs to the Xilinx engine (through /dev/crypto or using the cryptodev module) can trigger this bug just by submitting enough requests, especially in parallel.

Example PoC (theoretical)

// This will just cause lots of crypto requests
for (int i = ; i < 10000; i++) {
    submit_crypto_job(); // user code that uses the crypto engine
}

Run this as a non-root user (if permissions allow), and watch dmesg. If the bug is unpatched, warnings will appear, and possibly a system crash.

References and Further Reading

- Mainline Linux Patch
- NVD Listing for CVE-2024-26877
- Xilinx ZynqMP Documentation
- Linux Crypto API Documentation
- HOWTO: Writing Secure Linux Kernel Modules

In Summary

CVE-2024-26877 is a great example of how even small mistakes in interrupt handling can undermine kernel security and stability. If you’re on a vulnerable kernel and use Xilinx crypto hardware, patch immediately!

Timeline

Published on: 04/17/2024 11:15:09 UTC
Last modified on: 05/04/2025 08:58:39 UTC