In the ever-evolving world of Linux security, kernel vulnerabilities stand out for their potential severity. Recently, CVE-2024-26974 was identified and patched—a use-after-free (UAF) bug triggered by a race condition in the crypto subsystem, specifically within the Intel QuickAssist Technology (QAT) driver. This post breaks down the vulnerability, its trigger conditions, the technical root cause, and the open-source fix, along with proof-of-concept details. All technical jargon is kept simple for broader understanding.

What Is CVE-2024-26974?

CVE-2024-26974 affects the Linux kernel’s handling of PCI error recovery when using the Intel QAT crypto hardware. The vulnerability is classified as a race condition that can cause a use-after-free error, which may lead to kernel crashes or information leaks.

How the Vulnerability Happens

During Advanced Error Reporting (AER) recovery, the intel_qat kernel driver must reset affected PCI devices. The reset operation uses a structure called reset_data to synchronize the process. Under heavy load or slow device response (when the reset takes over 10 seconds), the function that schedules the reset hits a timeout and frees the reset_data structure thinking the process is done.

BUT:
The worker function (the one actually performing the device reset) might still reference the just-freed reset_data for completion notification — leading to use-after-free (UAF).

Message from Linux Kernel Bug

BUG: KFENCE: use-after-free read in adf_device_reset_worker+x38/xa [intel_qat]
Use-after-free read at x00000000bc56fddf (in kfence-#142):
adf_device_reset_worker+x38/xa [intel_qat]
process_one_work+x173/x340

Having another process or kernel thread waiting for completion on this operation.

An attacker with the ability to provoke device errors could potentially crash the kernel, or in rare scenarios, escalate privileges by reading freed (and reused) memory.

Minimal Proof-of-Concept (PoC)

While exploiting kernel UAFs is non-trivial and hardware-specific here, a broad outline for exploitation:

// Simplified: forcibly inject error, wait for timeout
device_ioctl(QAT_DEV, INJECT_AER_ERROR);

// Wait just over 10 seconds so reset times out
sleep(11);

// Check kernel logs for use-after-free (via dmesg or journalctl)

Note: This assumes abilities typically only available to root or with special hardware access.

How the Bug Was Fixed

The primary problem: freeing memory (reset_data) too early if a timeout occurs.

The memory associated with reset_data is NO LONGER always freed immediately on timeout.

- The freeing happens in the worker, after confirming through completion_done() if anyone is still waiting. If yes, free in the scheduler; if not, free in the worker.

Relevant Patch Snippet

if (!completion_done(&reset_data->completion)) {
    // Completion still pending: scheduler frees it after worker finishes
} else {
    // Timeout: worker checks and safely frees
    kfree(reset_data);
}

References

- LKML Patch Discussion
- Upstream Kernel Commit
- Mitre CVE Description

Defensive Suggestions

- Update your kernel: Any Linux system using the Intel QAT hardware crypto accelerator should patch promptly.
- Restrict device access: Only trusted users should access device controls involving PCI reset or error injection.

Conclusion

CVE-2024-26974 is a nuanced example of how complex driver state, error recovery, and multi-threading in the Linux kernel can lead to subtle security holes. Root cause: freeing memory before it’s truly safe, depending on how long a device takes to reset. The patch secures this by moving the memory management decision into the right context.

For more, consult the upstream kernel fix and always keep servers patched!


*Exclusive commentary:*
This case is a modern lesson in why defensive programming and deep understanding of multi-threaded workflows are mandatory in kernel development—and how a small mistake in timing can have big repercussions for security. Stay tuned for more kernel security deep-dives!

Timeline

Published on: 05/01/2024 06:15:14 UTC
Last modified on: 12/23/2024 14:00:33 UTC