CVE-2026-64316

What it actually does

This flaw affects the Linux kernel CAAM cryptographic accelerator driver. When dynamic debug is enabled and relevant CAAM debug statements are activated, key material handled by *_setkey() and gen_split_key() can be emitted as hexadecimal dumps into kernel debug output or logs. The vulnerability does not directly provide code execution or privilege escalation; its impact is confidentiality loss of cryptographic secrets that may protect disk, network, application, or protocol data, depending on how CAAM is used by the system.

Why it matters to the business

If exposed, sensitive encryption or authentication keys could be recorded in system logs, debug buffers, or log aggregation platforms, allowing anyone with access to those records to decrypt protected data or impersonate trusted cryptographic operations. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity indicated, so urgency is primarily highest for systems using CAAM hardware with dynamic debug enabled or centralized collection of kernel logs.

How an attack unfolds

An attacker generally needs some level of access to kernel logs, debug output, crash artifacts, or centralized logging data rather than a direct network exploit path. The vulnerable condition occurs when the CAAM driver processes keys while CONFIG_DYNAMIC_DEBUG is enabled and the relevant debug logging sites are active. During key setup or split-key generation, sensitive key bytes may be printed as hexadecimal data. An attacker who can read dmesg, journald, syslog, debugfs dynamic debug output, crash dumps, or a SIEM/logging platform receiving kernel logs may recover the key material and use it to decrypt captured data, forge authentication, or compromise dependent cryptographic protections.

How to fix it

Upgrade to a kernel version that includes the CAAM driver change replacing sensitive key dumps with print_hex_dump_devel(), or apply the vendor/backport patch for this issue when available. Because no product-specific fixed versions were provided, use the fixed kernel package or advisory from the relevant Linux distribution, device vendor, or SoC platform vendor. As mitigations, disable dynamic debug in production kernels where feasible, ensure CAAM driver debug call sites are not enabled, restrict access to dmesg and kernel logs, avoid collecting verbose kernel debug output into centralized logging, and rotate any cryptographic keys that may have been exposed while vulnerable debug logging was enabled.

How to confirm the fix worked

Confirm that the running kernel includes the patched CAAM driver code and that vendor package metadata identifies the fix for this vulnerability. Validate that CONFIG_DYNAMIC_DEBUG is disabled where not needed, or that no CAAM dynamic debug entries are enabled under /sys/kernel/debug/dynamic_debug/control. Review boot and runtime logging configuration to ensure unprivileged users cannot read kernel logs, for example through dmesg restrictions and journald/syslog permissions. If debug logging was previously enabled, inspect retained logs for CAAM-related key-sized hexadecimal dumps and rotate any potentially exposed keys.

Typical attack path

1. Identify Linux systems using the CAAM cryptographic accelerator driver, commonly on platforms with NXP/Freescale CAAM hardware.
2. Determine whether the kernel was built with CONFIG_DYNAMIC_DEBUG and whether CAAM dynamic debug call sites are enabled.
3. Wait for or trigger legitimate cryptographic operations that invoke CAAM key setup or split-key generation paths.
4. Access kernel logs, debug output, dmesg, journald, syslog, crash dumps, or centralized log aggregation records.
5. Search the collected output for CAAM-related hexadecimal dumps associated with key setup or split-key generation.
6. Extract exposed key material and use it to decrypt protected data, validate guesses, or impersonate cryptographic operations where the recovered key is valid.

How to detect it

To determine whether exploitation or accidental exposure already occurred, focus on evidence of sensitive key material written to logs rather than network indicators. Review kernel log sources such as dmesg output, journald kernel facility records, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, and centralized SIEM/log aggregation data. Check whether dynamic debug was enabled for CAAM by reviewing /sys/kernel/debug/dynamic_debug/control, boot-time debug parameters, configuration management, and administrative shell history. Search for CAAM driver log entries near cryptographic key setup operations and for unusually long contiguous hexadecimal strings consistent with key material. Also review access logs for users, services, or API tokens that read kernel logs, debugfs, crash artifacts, or exported SIEM records during the exposure window.

• /sys/kernel/debug/dynamic_debug/control
• drivers/crypto/caam
• caam
• gen_split_key
• setkey
• CONFIG_DYNAMIC_DEBUG
• dynamic_debug
• dyndbg
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /run/log/journal
• dmesg
• kernel: caam
• caam_jr
• caamalg
• caamhash
• caam_rsa

What your security team should do

• Inventory Linux systems using CAAM hardware or the caam kernel driver, prioritizing embedded, appliance, edge, and NXP/Freescale-based platforms.
• Patch affected kernels through the operating system or device vendor once a fixed package is available for the deployed platform.
• Immediately disable CAAM dynamic debug logging and remove any persistent dynamic debug configuration that enables CAAM driver debug output.
• Restrict access to kernel logs, dmesg, debugfs, crash dumps, journald, syslog, and centralized log platforms that may contain historical debug output.
• Search historical logs for CAAM-related hexadecimal key dumps and treat any recovered key-like material as compromised.
• Rotate encryption, authentication, or integrity keys processed by affected systems during periods when dynamic debug output may have been enabled.
• Tune logging pipelines to avoid ingesting verbose kernel debug data from production systems unless explicitly required and access-controlled.