CVE-2026-43330

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the CAAM cryptographic accelerator driver’s HMAC key handling. When an HMAC key longer than the hash block size is supplied, the driver allocates a DMA-aligned temporary buffer but copies from the original key using the aligned length rather than the actual key length. That can cause an out-of-bounds read from kernel memory adjacent to the key buffer and may destabilize or corrupt nearby kernel memory during subsequent processing. On affected systems with the CAAM driver in use, a local user or process able to submit HMAC operations to the kernel crypto API may be able to crash the system, disclose sensitive kernel memory, or potentially escalate privileges, depending on allocator layout, hardware path, kernel hardening, and reachable crypto interfaces.

Why it matters to the business

A successful exploit could affect the confidentiality, integrity, and availability of Linux systems that use the CAAM crypto driver, particularly embedded, appliance, network, storage, and edge platforms built on SoCs that include CAAM hardware. The most likely operational consequence is a kernel crash or device reboot, but the CVSS impact allows for more severe outcomes such as local privilege escalation or exposure of sensitive kernel memory. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so it is lower urgency than actively exploited kernel flaws; however, it should still be prioritized on systems where untrusted local users, containers, sandboxed workloads, VPN/IPsec stacks, cryptographic services, or appliance features can exercise kernel HMAC operations.

How an attack unfolds

An attacker first needs local code execution or access to a local interface that can cause the Linux kernel to perform HMAC operations through the affected CAAM crypto driver. The attacker then submits an HMAC key that is longer than the relevant hash block size, causing the driver to enter the path that hashes the long key into a real key. Because the vulnerable code rounds the temporary copy length up to the DMA cache-alignment boundary but reads from the original key buffer using that rounded length, the kernel reads beyond the supplied key buffer. With repeated attempts and careful heap shaping, this out-of-bounds access may result in kernel memory disclosure, memory corruption side effects, or a kernel fault. In the simplest case, exploitation causes denial of service through a kernel oops, panic, or device reset; in a more advanced scenario, a capable local attacker could attempt to turn the memory corruption primitive into privilege escalation. There are no named threat actors or public exploitation campaigns reported for this issue in the provided data.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or hardware vendor that includes the CAAM driver fix replacing the unsafe kmemdup-based copy with allocation followed by a bounded memcpy. No exact fixed version was provided, so remediation should be based on vendor advisories, downstream kernel package changelogs, or confirmation that the upstream fix for the CAAM long HMAC key overflow is present. Reboot into the fixed kernel after installation and remove or disable vulnerable kernels where possible. If immediate patching is not possible, reduce exposure by disabling or unloading the CAAM crypto driver if it is not required, preventing untrusted users or workloads from accessing local crypto interfaces, restricting container capabilities and device access, and limiting services that allow user-controlled HMAC key material to reach kernel crypto APIs. Mitigations should be treated as temporary because kernel memory-corruption issues are difficult to fully contain without the code fix.

How to confirm the fix worked

Confirm the running kernel is the patched vendor kernel, not merely that an update package is installed. Validate with package inventory, uname output, and vendor advisory mapping. Check whether CAAM support is present or loaded using kernel configuration and module/runtime indicators such as CONFIG_CRYPTO_DEV_FSL_CAAM, lsmod, /proc/modules, /proc/crypto, and dmesg entries referencing caam. Review the kernel source or vendor changelog for the specific fix pattern: the vulnerable kmemdup copy of the DMA-aligned length should be replaced by kmalloc plus memcpy limited to the original key length. Where safe, use a non-production test system with the same hardware and kernel lineage to run HMAC crypto self-tests using long keys and confirm there are no KASAN reports, kernel oopses, panics, or CAAM driver faults. Do not run proof-of-concept crash tests on production systems.

Typical attack path

1. Gain local execution on an affected Linux system, or access a local service/container path that can request HMAC operations from the kernel crypto API.
2. Confirm the system uses the affected CAAM crypto driver and that CAAM-backed HMAC algorithms are available.
3. Prepare HMAC requests using keys longer than the algorithm block size so the vulnerable long-key handling path is used.
4. Repeat requests with controlled key sizes and timing to trigger the DMA-aligned over-read and influence kernel memory layout.
5. Observe effects such as kernel warnings, crashes, service interruption, memory disclosure, or privilege-escalation behavior depending on exploit sophistication.
6. Use any gained elevated privileges or disclosed data to persist, move laterally, or tamper with system controls.

How to detect it

Retrospective detection should focus on evidence of local probing, abnormal HMAC activity, and kernel instability around the CAAM crypto driver. Review kernel logs, persistent journal logs, syslog, audit logs, crash dumps, kdump/vmcore artifacts, EDR telemetry, and container runtime logs for CAAM-related faults, kernel oopses, KASAN reports, panics, or repeated process crashes preceding a reboot. Look for local processes using AF_ALG or other crypto interfaces shortly before kernel faults, especially from unexpected users, containers, temporary directories, test binaries, interpreters, or recently dropped executables. On systems with auditd or eBPF telemetry, examine socket creation and use of AF_ALG, module loading, access to crypto-related procfs entries, and suspicious attempts to enumerate /proc/crypto or loaded CAAM modules. Because no public exploit indicators or campaign-specific artifacts are provided, absence of these indicators does not prove non-exploitation; kernel memory-corruption exploitation may leave only a crash, reset, or no durable artifact.

• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• Unable to handle kernel paging request
• general protection fault
• Kernel panic - not syncing
• Oops:
• kernel BUG at
• caam
• caam_jr
• caamhash
• caamalg
• fsl-caam
• /proc/crypto
• AF_ALG
• algif_hash
• CONFIG_CRYPTO_DEV_FSL_CAAM

What your security team should do

• Identify Linux systems, appliances, and embedded platforms using NXP/Freescale CAAM hardware or the CAAM kernel crypto driver.
• Prioritize patching systems that allow shell access, multi-user workloads, containers, plugins, VPN/IPsec termination, cryptographic APIs, or other paths where untrusted input can influence HMAC keys.
• Upgrade to a vendor-supported kernel containing the CAAM long HMAC key fix and reboot into the patched kernel.
• If patching is delayed, disable the CAAM driver or remove CAAM-backed HMAC algorithm exposure where operationally feasible.
• Restrict local access and container privileges on affected systems, especially access to AF_ALG, kernel crypto interfaces, device nodes, and privileged capabilities.
• Enable and monitor kernel crash, oops, panic, audit, and EDR telemetry for signs of repeated crypto-driver faults or suspicious local probing.
• For high-assurance systems, perform post-patch regression testing of cryptographic workloads that rely on CAAM acceleration.
• Track vendor advisories because fixed versions vary by distribution, appliance firmware, and downstream long-term-support kernel branch.