CVE-2026-45986

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel crypto ccree driver. When cc_mac_digest() calls cc_map_hash_request_final() and that mapping operation fails, the driver previously failed to release mapped result resources. Repeatedly triggering this error path can leak kernel memory, eventually degrading system stability or exhausting memory and causing service disruption, process termination by the OOM killer, or a kernel crash. The flaw requires local access with low privileges and does not provide confidentiality or integrity impact by itself.

Why it matters to the business

An attacker or malicious local workload on an affected Linux system could cause instability or downtime by exhausting kernel memory. The most likely operational consequence is degraded availability of systems using the affected ccree crypto driver, including interrupted applications, forced reboots, or service outages. The CVSS score is moderate and EPSS is very low, it is not listed in CISA KEV, and no mature public exploitation is currently indicated, so remediation should be handled through normal kernel patching priorities unless the affected driver is present on critical or multi-tenant systems.

How an attack unfolds

An attacker first needs local code execution on a system running an affected Linux kernel with the ccree crypto driver available and in use. The attacker then repeatedly invokes crypto operations that reach the ccree MAC digest path and intentionally or naturally cause cc_map_hash_request_final() to fail, such as by creating memory pressure or malformed/unusual request conditions. Each failed operation can leave mapped resources unreleased because the error path omits cc_unmap_result(). Over time, the leaked kernel memory accumulates. If repeated enough, the system may experience increasing memory pressure, OOM-killer activity, degraded application performance, failed allocations, or a kernel panic/reboot, resulting in denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the ccree driver memory leak in cc_mac_digest(), specifically the change that calls cc_unmap_result() when cc_map_hash_request_final() fails. If vendor fixed package versions are not available, use the latest supported kernel from the operating system or appliance vendor once it includes the patch. Reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by disabling or unloading the ccree driver if it is not required, limiting local shell access, restricting untrusted workloads on affected systems, and monitoring for abnormal kernel memory growth or OOM events. Mitigations are risk-reduction only; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build that contains the ccree memory-leak fix, not merely that the package is installed. Validate with the distribution vendor advisory, kernel changelog, or source package to ensure the patch adding cc_unmap_result() on the cc_map_hash_request_final() failure path is present. After patching, reboot and verify the active kernel version with uname -a or equivalent inventory tooling. Check whether the ccree module is present or loaded using lsmod, modinfo, /proc/modules, or kernel configuration data. For exposure validation, identify systems with the affected kernel and ccree driver enabled; systems without the driver or code path reachable have reduced practical exposure. For functional validation in test environments, run crypto workloads that exercise the driver while monitoring kernel memory, dmesg, and OOM activity before and after the fix.

Typical attack path

1. Gain local access to an affected Linux system, such as through a shell, compromised application account, container escape prerequisite, or malicious local workload.
2. Confirm the affected kernel includes and exposes the ccree crypto driver or a dependent crypto path.
3. Generate repeated MAC/digest crypto requests that exercise cc_mac_digest().
4. Induce or wait for failures in cc_map_hash_request_final(), for example under resource pressure.
5. Repeat the trigger to accumulate leaked kernel memory.
6. Cause system instability, OOM-killer events, service disruption, or a crash/reboot due to memory exhaustion.

How to detect it

Retrospective detection should focus on evidence of abnormal kernel memory exhaustion and repeated failures around the ccree crypto driver rather than a single definitive exploit signature. Review kernel logs, system journals, crash dumps, and monitoring telemetry for repeated ccree, crypto, DMA mapping, allocation failure, OOM-killer, kernel panic, or unexpected reboot events. Useful log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, audit logs for suspicious local process activity, EDR process telemetry, and system performance metrics showing unexplained kernel memory growth. Look for repeated local processes invoking crypto-heavy operations immediately before memory pressure or OOM events. If kdump/vmcore data is available, inspect for memory pressure and call traces involving ccree, cc_mac_digest(), cc_map_hash_request_final(), or crypto hash request finalization paths. Absence of these artifacts does not prove non-exploitation, because a memory leak may leave only generic resource exhaustion symptoms.

• ccree
• cc_mac_digest
• cc_map_hash_request_final
• cc_unmap_result
• Out of memory
• oom-killer
• invoked oom-killer
• Killed process
• page allocation failure
• kernel panic
• Kernel panic - not syncing
• BUG: unable to handle kernel
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash
• /proc/modules
• /sys/module/ccree

What your security team should do

• Inventory Linux systems for affected kernel versions and determine whether the ccree crypto driver is present or loaded.
• Prioritize patching for critical systems, multi-user systems, shared compute platforms, and systems running untrusted local workloads.
• Apply the latest vendor-supported kernel that includes the ccree cc_mac_digest() memory-leak fix and reboot into the patched kernel.
• If patching is delayed and the driver is not required, disable or blacklist the ccree module according to vendor guidance.
• Restrict local access and untrusted workload execution on affected systems until remediation is complete.
• Monitor affected systems for kernel memory pressure, OOM-killer events, abnormal reboots, and ccree-related kernel errors.
• Because this issue is not in KEV, is not associated with ransomware use, and has very low EPSS, handle it through standard vulnerability management unless asset criticality raises the risk.