CVE-2026-64304

What it actually does

This is a local Linux kernel memory-corruption flaw in the Intel QuickAssist Technology (QAT) crypto driver’s RSA CRT key handling path. The generic RSA parser permits CRT parameters whose lengths are up to the RSA modulus size, but the QAT driver allocates half-modulus-size DMA buffers for CRT components and right-aligns each component without first verifying that it fits. If a local privileged-capable caller can cause the kernel to load or use an RSA CRT key with an oversized p, q, dp, dq, or qinv component through the affected QAT crypto path, the length calculation can underflow and memcpy can write outside the intended DMA buffer. The result can be kernel memory corruption with potential confidentiality, integrity, and availability impact, including kernel crash, data corruption, or possible local privilege escalation depending on kernel configuration, driver exposure, and exploit reliability.

Why it matters to the business

Systems using affected Linux kernels with the QAT crypto driver enabled may be exposed to local attacks that can crash systems or potentially allow a user or compromised process with local access to gain elevated control. This is most relevant for servers using Intel QAT acceleration for cryptographic workloads, including high-throughput TLS, VPN, storage, or service-provider environments. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and had no public exploit maturity reported in the provided data, so urgency is highest for multi-user Linux systems, shared hosting, container platforms with access to kernel crypto interfaces, and production systems where QAT is enabled.

How an attack unfolds

An attacker first obtains local code execution or access to a context that can request RSA operations through the Linux kernel crypto API backed by the QAT driver. They then supply or trigger use of a malformed RSA CRT private key where one or more CRT components are larger than the half-size buffer the QAT driver expects. When the driver prepares the key for hardware offload, it allocates half-size DMA buffers for each CRT component and attempts to right-align the oversized value. Because the vulnerable code does not reject the oversized component, the offset calculation underflows and the subsequent memory copy writes outside the allocated buffer. In the simplest case this causes a kernel fault or system instability; with a reliable memory-corruption primitive, an attacker may attempt to influence adjacent kernel/DMA memory to escalate privileges or bypass kernel protections. Exploitation is local, requires privileges sufficient to reach the vulnerable crypto path, and depends on QAT hardware/driver availability and kernel configuration.

How to fix it

Upgrade to a Linux kernel version that includes the QAT RSA CRT component length validation fix. The corrected behavior rejects CRT components larger than half the modulus size and falls back to the non-CRT path rather than writing out of bounds. Because no exact fixed package versions were provided, use vendor advisories for the deployed distribution or kernel source tree to identify the first fixed kernel build. Prioritize systems with the qat, qat_4xxx, qat_c3xxx, qat_c62x, qat_dh895xcc, or related Intel QAT modules loaded. If immediate patching is not possible, reduce exposure by unloading or blacklisting affected QAT driver modules where operationally feasible, disabling QAT crypto offload, restricting local shell access, limiting untrusted workloads, and ensuring containerized workloads cannot access kernel crypto interfaces or device nodes that increase reachability. Reboot after kernel updates or module changes to ensure the vulnerable code is no longer active.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed package, contains the upstream fix that adds length checks for RSA CRT components in the QAT driver. Validate the currently booted kernel with uname -a and compare it with the distribution’s fixed advisory. Check whether QAT modules are loaded with lsmod | grep -i qat and whether QAT devices are present with lspci | grep -i quickassist. If QAT is not needed and mitigation was chosen, confirm the modules are unloaded and blacklisted, then verify they do not reload after reboot. For source-based kernels, inspect the QAT RSA CRT setkey logic and confirm each CRT component rejects len > half_key_sz as well as zero length before copying. Operational validation should include checking that crypto services still function after upgrade or QAT disablement and that no new kernel oops, DMA, or crypto API errors appear in system logs.

Typical attack path

1. Identify a Linux system running an affected kernel with the Intel QAT crypto driver loaded and usable.
2. Obtain local access through a shell, compromised service account, container escape prerequisite, or other local execution path.
3. Reach a kernel crypto API path that routes RSA CRT private-key handling to the QAT driver.
4. Submit or cause processing of an RSA CRT key with an oversized CRT component such as p, q, dp, dq, or qinv.
5. Trigger QAT RSA key setup so the driver performs the vulnerable copy into undersized DMA buffers.
6. Cause kernel memory corruption, leading to denial of service or, if exploit development is successful, possible local privilege escalation.

How to detect it

Retrospective detection is difficult because successful exploitation would appear as kernel memory corruption rather than a clean application-layer event. Focus on hosts with QAT modules loaded and review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash dump infrastructure for signs of QAT RSA activity followed by kernel oops, panic, general protection fault, page fault, slab corruption, DMA mapping errors, or crypto API errors. Correlate events with local user activity, newly created processes, test binaries, unexpected use of cryptographic tooling, or workloads submitting unusual RSA private keys. On systems configured for crash dumps, inspect vmcores for call traces involving QAT RSA key setup, Intel QAT modules, the kernel crypto akcipher API, or memcpy-related faults. Since no known public exploit or actor activity was provided, detection should emphasize anomaly hunting and crash forensics rather than fixed network indicators.

• qat_rsa_setkey_crt
• crypto: qat
• intel_qat
• qat_4xxx
• qat_c3xxx
• qat_c62x
• qat_dh895xcc
• QuickAssist
• alg: akcipher
• kernel BUG
• general protection fault
• BUG: unable to handle page fault
• Oops:
• Kernel panic
• slab-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• DMA-API:
• RSA CRT

What your security team should do

• Inventory Linux systems with Intel QAT hardware or QAT kernel modules loaded and prioritize those for patching or mitigation.
• Apply the vendor-provided fixed kernel and reboot affected systems; confirm the running kernel is the patched version.
• If patching is delayed, unload or blacklist QAT driver modules and disable QAT crypto offload where business impact is acceptable.
• Prioritize multi-user systems, shared compute platforms, externally managed hosting nodes, and systems running untrusted local workloads.
• Restrict local access and review whether containers, service accounts, or batch jobs can reach kernel crypto APIs or QAT device interfaces.
• Monitor kernel logs for oops, general protection faults, DMA faults, QAT errors, and crypto API failures that could indicate attempted triggering.
• Because this is not currently KEV-listed and EPSS is low, track vendor advisories and exploit intelligence, but do not deprioritize exposed QAT-enabled production systems where local compromise could become full host compromise.