CVE-2026-93161

What it actually does

Leaves expanded AES key schedule containing cryptographic material on the kernel stack after qat_alg_xts_reverse_key() completes without explicit clearing.

Why it matters to the business

Increases risk of exposure of encryption keys on systems using Intel QAT hardware acceleration, potentially allowing unauthorized access to protected data and requiring urgent patching of affected Linux kernels.

How an attack unfolds

An attacker with the ability to inspect kernel stack memory (via local access, another vulnerability, or debugging interfaces) triggers an XTS AES operation through the QAT driver, then reads the uncleared crypto_aes_ctx structure from the stack frame to recover key material.

How to fix it

Update the Linux kernel to a version containing the memzero_explicit() clearing fix for the QAT crypto path; rebuild and reboot affected systems. Where immediate patching is not possible, restrict use of QAT XTS operations and monitor for related memory disclosure issues.

How to confirm the fix worked

Confirm the presence of the memzero_explicit() call after the key schedule copy in qat_alg_xts_reverse_key(); inspect kernel source or running binary for the clearing instruction and verify no older vulnerable QAT driver modules remain loaded.

Typical attack path

1. Obtain local or kernel-memory read access on a Linux system using the QAT driver
2. Trigger qat_alg_xts_reverse_key() via an XTS encryption operation
3. Locate and extract the uncleared AES key schedule from the stack frame
4. Use recovered keys to decrypt protected data or escalate privileges

How to detect it

Examine kernel logs, memory dumps, or crash reports for references to qat_alg_xts_reverse_key or crypto_aes_ctx structures; look for unexpected memory reads or debug accesses around QAT crypto operations in system audit trails.

What your security team should do

• Prioritize kernel updates on all systems using Intel QAT hardware within the next maintenance window
• Audit workloads relying on QAT XTS encryption and migrate to software fallbacks if patches cannot be applied promptly
• Add kernel version checks to vulnerability scanning and asset inventory processes
• Review logging for any QAT driver initialization events that could indicate exposure windows