CVE-2026-43044

What it actually does

CVE-2026-43044 is a Linux kernel memory corruption flaw in the CAAM crypto driver. When an HMAC key longer than the hash block size is supplied, the driver copies the key and hashes it into the effective key. The code calculated a DMA cache-aligned allocation size but failed to use that rounded size for the actual allocation, allowing DMA-related writes for the hashed key operation to corrupt adjacent kernel memory. Because this occurs in kernel space, successful exploitation could affect confidentiality, integrity, and availability, including possible kernel crash, data corruption, or privilege escalation depending on hardware, configuration, and reachable crypto interfaces.

Why it matters to the business

Systems using affected Linux kernels with the CAAM crypto driver enabled may be exposed to local attacks that can crash systems or potentially allow a low-privileged local user to gain elevated control. The CVSS score is high, but the attack requires local privileges and there is currently no known public exploit maturity, no CISA KEV listing, no known ransomware use, and a very low, flat EPSS score, indicating limited observed exploitation likelihood at this time. Operational risk is highest for embedded, appliance, network, industrial, and ARM-based platforms that rely on NXP/Freescale CAAM hardware acceleration for cryptographic operations.

How an attack unfolds

An attacker first needs local code execution or the ability to cause a local process to invoke kernel cryptographic operations backed by the CAAM driver. They then submit or influence use of an HMAC key longer than the algorithm block size. The vulnerable driver allocates a buffer based on the unrounded key length while DMA/cache alignment requirements assume a larger rounded length. During the key hashing/preparation path, the CAAM DMA operation can write beyond the allocated buffer and corrupt neighboring kernel memory. A reliable exploit would require shaping kernel heap layout so the out-of-bounds corruption modifies useful adjacent data rather than simply crashing the system. In the most severe case, this could be turned into local privilege escalation; in less controlled cases it may result in kernel panic, service disruption, or silent memory corruption.

How to fix it

Apply a Linux kernel update from the operating system, appliance, embedded platform, or hardware vendor that includes the upstream CAAM driver fix for this issue. No exact fixed package versions were provided in the input, so use vendor advisories and distribution security trackers to identify the corrected kernel build for each platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the CAAM crypto driver if it is not required, disabling CAAM-backed crypto acceleration in favor of software crypto where supported, restricting local shell/code execution, limiting access to interfaces that allow untrusted users to request HMAC operations, and applying standard local hardening such as least privilege, container isolation, kernel lockdown features, and module loading restrictions. Because this is kernel code, a reboot is normally required after installing the fixed kernel for remediation to take effect.

How to confirm the fix worked

Confirm exposure by checking whether systems run an affected kernel build and whether the CAAM driver is present, loaded, or built into the kernel. Review vendor kernel changelogs for the CAAM long HMAC key DMA alignment fix, then verify the running kernel after reboot with standard OS package and kernel version commands. Validate mitigation by confirming the fixed kernel is booted, the vulnerable CAAM module is not loaded if disabled, or the relevant crypto driver path is no longer available to untrusted workloads. On Linux systems, useful checks include inspecting the running kernel version, installed kernel package version, loaded modules, kernel config, and crypto algorithm registrations. A negative scan should not rely only on upstream version numbers because distributions often backport kernel fixes without changing to the latest upstream release.

Typical attack path

1. Obtain local access to a vulnerable Linux system, such as a shell, compromised service account, container escape prerequisite, or ability to run unprivileged code.
2. Confirm the affected kernel has the CAAM crypto driver present and usable, typically on systems with compatible crypto acceleration hardware.
3. Invoke a kernel crypto API path that uses CAAM-backed HMAC processing.
4. Supply or cause use of an HMAC key longer than the relevant hash algorithm block size.
5. Trigger the vulnerable long-key handling path where the copied key buffer is not allocated with the required DMA cache-aligned size.
6. Abuse the resulting adjacent kernel memory corruption to crash the host or, with sufficient exploit reliability, alter kernel state for privilege escalation.

How to detect it

There are no public exploit-specific indicators in the provided information, so detection should focus on signs of attempted triggering, kernel memory corruption, and post-exploitation local privilege escalation. Review kernel logs, persistent journal logs, system crash dumps, audit logs, and endpoint telemetry for CAAM driver errors, DMA mapping/cache alignment warnings, kernel oops or panic events near crypto or HMAC activity, unexpected reboots, and processes repeatedly opening kernel crypto interfaces. On systems with auditd or EDR, correlate suspicious local users or low-privileged processes invoking AF_ALG crypto sockets or crypto-related workloads shortly before kernel faults. For suspected compromise, collect vmcore/kdump artifacts, dmesg/journal history, loaded module lists, running kernel package metadata, process execution history, authentication logs, and evidence of privilege escalation such as new setuid files, unexpected root shells, modified sudoers files, or unauthorized kernel module activity.

• caam
• caam_jr
• CAAM
• crypto: caam
• DMA corruption
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• Oops:
• Kernel panic
• Unable to handle kernel paging request
• algif_hash
• AF_ALG
• /proc/crypto
• /dev/crypto
• /var/crash
• /var/lib/systemd/coredump
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patching systems that use NXP/Freescale CAAM crypto hardware, embedded Linux images, appliances, edge devices, and multi-user Linux hosts where untrusted local code can run.
• Inventory affected kernels and determine whether the CAAM driver is enabled, loaded, or compiled into the kernel.
• Use vendor-specific advisories to identify fixed kernel packages, then schedule kernel updates and reboots through normal change management.
• If patching is delayed, disable CAAM crypto acceleration where operationally feasible and restrict local users or workloads from invoking kernel crypto paths with attacker-controlled HMAC keys.
• Increase monitoring for kernel crashes, oops messages, CAAM driver errors, unexpected reboots, and suspicious local privilege escalation behavior on potentially affected systems.
• Do not treat the low EPSS and lack of KEV status as a reason to ignore the issue; treat it as lower internet-scale urgency but still high impact for exposed local or multi-tenant systems.
• For embedded products and appliances, confirm whether the vendor firmware includes the kernel fix rather than assuming general-purpose Linux distribution guidance applies.