CVE-2026-64315

What it actually does

This is a Linux kernel information-disclosure flaw in the CAAM crypto driver. When the kernel is built with CONFIG_DYNAMIC_DEBUG and CAAM dynamic-debug logging is enabled, key-setting code paths can emit sensitive cryptographic key material as hexadecimal dumps into kernel debug output. An attacker with local privileges who can enable or read kernel/debug logs may recover keys used by CAAM-backed crypto operations. The flaw does not directly provide remote code execution, but exposed keys can undermine confidentiality and, depending on what the keys protect, enable decryption, forgery, tampering, or impersonation.

Why it matters to the business

Systems using affected Linux kernels with the CAAM crypto driver may unintentionally expose encryption or authentication keys through local kernel logs. If exploited, protected data, VPN or storage secrets, device trust anchors, or application-layer cryptographic material could be compromised. The issue is not currently listed in CISA KEV, has no known exploit maturity, and has a low EPSS score, so broad automated exploitation is not indicated; however, environments that rely on CAAM-backed cryptography, embedded Linux, appliances, or shared administrative access should treat it seriously because key leakage can have long-lived operational consequences.

How an attack unfolds

An attacker first obtains local access to a Linux system that includes the CAAM crypto driver and a vulnerable kernel build. The attacker then determines whether CONFIG_DYNAMIC_DEBUG is enabled and whether debugfs or dynamic-debug controls are accessible. If permitted, they enable verbose dynamic-debug output for CAAM-related code paths or wait for an administrator or diagnostic process to have enabled it. They trigger, or wait for, cryptographic operations that call CAAM setkey routines. The vulnerable driver emits key material as hex dumps to kernel debug output. The attacker reads kernel logs through interfaces such as dmesg, journalctl, /dev/kmsg, or collected log files and extracts the leaked keys for later decryption, credential compromise, data forgery, or lateral movement.

How to fix it

Upgrade to a Linux kernel release, vendor kernel, or distribution backport that includes the CAAM driver fix changing sensitive key dumps to development-only guarded output. No exact fixed package versions were provided, so use the relevant Linux distribution, appliance vendor, or kernel-stable advisory to identify the patched build. As mitigations until patching is complete, disable CAAM dynamic-debug logging, avoid enabling CONFIG_DYNAMIC_DEBUG on production kernels where feasible, restrict debugfs access, set kernel.dmesg_restrict=1, restrict access to /dev/kmsg and kernel journal logs, and prevent unprivileged users from reading kernel messages. Review log-forwarding pipelines to ensure kernel debug logs containing secrets are not stored broadly. Rotate any cryptographic keys that may have been exposed while CAAM dynamic debugging was enabled.

How to confirm the fix worked

Confirm that the running kernel or vendor package contains the CAAM fix, either by checking the vendor advisory/backport changelog or verifying that the CAAM setkey code uses protected development-only hex-dump behavior rather than runtime dynamic-debug key dumps. Validate that production kernels do not expose CAAM key material by checking dynamic-debug state under /sys/kernel/debug/dynamic_debug/control and confirming CAAM driver entries are not enabled for printing. Verify that kernel log access is restricted: kernel.dmesg_restrict should be enabled where appropriate, /dev/kmsg should not be readable by untrusted users, and debugfs should not be mounted or accessible except to trusted administrators. After patching, conduct a controlled test in a non-production environment to ensure CAAM cryptographic operations do not emit key-like hex dumps to dmesg, journalctl -k, or centralized kernel log sinks.

Typical attack path

1. Gain local authenticated access to a Linux system using the CAAM crypto driver.
2. Check whether CONFIG_DYNAMIC_DEBUG, debugfs, and dynamic-debug controls are available.
3. Enable or abuse existing dynamic-debug logging for CAAM driver code paths.
4. Trigger CAAM-backed cryptographic operations that invoke setkey routines, or wait for normal system activity to do so.
5. Read kernel/debug logs using dmesg, journalctl -k, /dev/kmsg, or centralized log collection.
6. Extract hexadecimal key material from CAAM-related debug output.
7. Use recovered keys to decrypt protected data, forge authenticated data, impersonate services, or persist access.

How to detect it

Investigate whether the system was in a vulnerable state by reviewing kernel configuration, dynamic-debug state, and debugfs access during the exposure window. Check audit logs, shell histories, EDR telemetry, and sudo logs for writes to /sys/kernel/debug/dynamic_debug/control that enabled CAAM or crypto-driver logging. Review process execution logs for use of dmesg, journalctl -k, cat /dev/kmsg, or log collection tools by unexpected users. Search kernel logs, journal entries, rsyslog files, and centralized SIEM indexes for CAAM-related debug output, setkey references, and long hexadecimal dumps near CAAM crypto activity. Because leaked material may look like ordinary hex debug output, treat any CAAM setkey-related dump during a period when dynamic debug was enabled as sensitive. If exploitation is suspected, preserve logs carefully, restrict further access, and rotate keys that could have been handled by CAAM-backed crypto operations.

• /sys/kernel/debug/dynamic_debug/control
• /dev/kmsg
• /proc/sys/kernel/dmesg_restrict
• drivers/crypto/caam
• file drivers/crypto/caam/* +p
• module caam +p
• func *_setkey +p
• journalctl -k
• dmesg
• kernel: caam
• setkey
• print_hex_dump

What your security team should do

• Inventory Linux systems, appliances, and embedded platforms that use the CAAM crypto driver, especially NXP/Freescale SoC-based systems.
• Prioritize patching systems where local users, operators, containers, or support processes can access kernel logs or dynamic-debug controls.
• Apply the vendor kernel update or backport containing the CAAM key-dump fix as soon as available.
• Immediately disable CAAM dynamic-debug logging and remove unnecessary debugfs exposure on production systems.
• Restrict kernel log access using kernel.dmesg_restrict, permissions on /dev/kmsg, journal access controls, and least-privilege administrative roles.
• Search historical kernel logs and centralized logging platforms for CAAM-related setkey or hex-dump output.
• If evidence of key exposure is found, rotate affected cryptographic keys and invalidate dependent secrets or tokens.
• Monitor for suspicious use of dmesg, journalctl -k, /dev/kmsg, or writes to /sys/kernel/debug/dynamic_debug/control by non-standard users or processes.