CVE-2026-46291

What it actually does

This is an information disclosure issue in the Linux kernel CAAM crypto driver. When the kernel is built with CONFIG_DYNAMIC_DEBUG and dynamic debug output is enabled for the affected CAAM hashing code path, hash_digest_key() can emit raw HMAC key bytes through kernel debug logging. The flaw does not directly grant code execution or privilege escalation, but it can expose cryptographic key material to anyone able to read kernel logs, persistent system journals, crash/debug bundles, or centralized log pipelines that collect kernel messages.

Why it matters to the business

Systems using affected Linux kernels with the CAAM hardware crypto driver may accidentally leak HMAC secrets into logs during debugging or verbose diagnostic collection. This can undermine authentication, message integrity, or application trust decisions that depend on those HMAC keys, and may require secret rotation if exposure is confirmed. The currently reported exploitation likelihood is low, it is not listed in CISA KEV, and no public exploit maturity is indicated, but the impact is meaningful where kernel logs are broadly accessible or exported to shared monitoring platforms.

How an attack unfolds

An attacker first needs a system running an affected Linux kernel with the CAAM crypto driver in use and dynamic debug support compiled in. The leak occurs when dynamic debug output is enabled for the vulnerable CAAM hash digest key path, either intentionally by an administrator during troubleshooting or by an attacker who already has sufficient privileges to alter dynamic debug settings. The attacker then triggers or waits for HMAC operations that exercise hash_digest_key(). The vulnerable code can print HMAC key bytes into kernel logs. If the attacker can read dmesg, journald kernel records, syslog files, crash dumps, diagnostic bundles, or a centralized log platform, they can recover the key material and potentially use it to forge or validate protected messages outside the original system context.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix changing the sensitive dump to print_hex_dump_devel(), or apply the vendor/backport patch for the affected distribution or appliance kernel. Because no exact fixed package versions were provided, use the relevant Linux distribution, hardware vendor, or appliance advisory to identify the corrected kernel build. As mitigations until patching is complete, disable dynamic debug for the CAAM crypto driver, avoid enabling verbose kernel debug logging on production systems, restrict access to dmesg and kernel logs, limit access to debugfs, prevent unprivileged users from reading kernel logs by enforcing dmesg restrictions, and review whether kernel messages are exported to shared log platforms. If key exposure is suspected, rotate affected HMAC keys and invalidate derived credentials or tokens that depended on them.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix or contains the patched CAAM code path using print_hex_dump_devel() rather than runtime key-byte dumps. Verify the system is not exposing CAAM dynamic debug output by checking dynamic debug controls under /sys/kernel/debug/dynamic_debug/control when debugfs is mounted. Confirm unprivileged users cannot read kernel logs, for example through dmesg restrictions and journal/syslog permissions. Exercise relevant HMAC workloads in a controlled test environment with CAAM enabled and verify that kernel logs no longer contain raw key-byte hex dumps from hash_digest_key() or CAAM hash digest operations.

Typical attack path

1. Identify a Linux system using the CAAM crypto driver and an affected kernel build.
2. Determine whether CONFIG_DYNAMIC_DEBUG is enabled and whether dynamic debug controls are accessible.
3. Enable or find already-enabled debug logging for the CAAM hash code path.
4. Trigger HMAC operations that call hash_digest_key().
5. Collect kernel log output from dmesg, journald, syslog, crash artifacts, support bundles, or centralized logging.
6. Extract leaked hexadecimal HMAC key bytes from the logs.
7. Use the recovered HMAC secret to forge signatures, validate protected messages, or assist further compromise depending on how the key is used.

How to detect it

Look for signs that dynamic debug was enabled for the CAAM crypto driver and that CAAM hash/HMAC operations emitted hex-formatted key material. Review kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent crash dumps, support bundles, and centralized log platforms. Search for CAAM crypto driver messages near HMAC or hash operation activity, especially messages referencing hash_digest_key or hex dumps of key-like byte sequences. Check /sys/kernel/debug/dynamic_debug/control, if available, for enabled entries matching CAAM crypto source files or hash_digest_key. Also review shell history, audit logs, and EDR telemetry for writes to dynamic debug control files that enable CAAM or crypto debug output. Because the issue is a passive secret leak through logging, exploitation may leave no network indicator; the most useful evidence is debug configuration changes and logs containing raw key bytes.

• hash_digest_key
• /sys/kernel/debug/dynamic_debug/control
• CONFIG_DYNAMIC_DEBUG
• drivers/crypto/caam
• caam
• dmesg
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• echo '*drivers/crypto/caam* +p' > /sys/kernel/debug/dynamic_debug/control
• echo 'func hash_digest_key +p' > /sys/kernel/debug/dynamic_debug/control

What your security team should do

• Prioritize patching Linux systems and vendor appliances that use NXP/Freescale CAAM hardware crypto acceleration, especially where kernel logs are centrally collected or accessible to support users.
• Inventory systems with CONFIG_DYNAMIC_DEBUG enabled and the CAAM driver loaded or available.
• Immediately disable CAAM-related dynamic debug logging on production systems unless it is required for a controlled investigation.
• Restrict access to dmesg, journald kernel records, syslog files, debugfs, crash dumps, and diagnostic bundles.
• Search current and retained logs for evidence of CAAM HMAC key dumps and treat any recovered key material as compromised.
• Rotate HMAC keys if logs show possible exposure, if support bundles were shared externally, or if log access cannot be confidently scoped.
• Update SIEM retention and access controls to treat kernel debug logs as potentially sensitive secret-bearing data.