CVE-2026-45959: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-45959 Overview

CVE-2026-45959 is a Linux kernel vulnerability in the AMD Cryptographic Coprocessor (CCP) crypto driver. The flaw stems from the incorrect use of the __cleanup(kfree) attribute on a local pointer variable assigned by a kmalloc-family function. When the variable goes out of scope, the address of the stack-resident local pointer is passed to kfree instead of the heap address returned by kmalloc. This results in an invalid deallocation of a stack address and triggers a kernel crash. The intended pattern, used elsewhere in the kernel tree, is __free(kfree). The code compiled silently because kfree accepts a void * parameter, which is type-compatible with the offending pointer-to-pointer.

Critical Impact
Local activity that exercises the affected CCP crypto code path can crash the kernel, leading to a denial-of-service condition on systems using AMD CCP cryptographic acceleration.

Affected Products

Linux kernel — crypto: ccp subsystem (AMD Cryptographic Coprocessor driver)
Kernel builds incorporating the affected __cleanup(kfree) annotation in the CCP driver
Distribution kernels that have not yet picked up the upstream stable fixes

Discovery Timeline

2026-05-27 - CVE-2026-45959 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45959

Vulnerability Analysis

The defect lives in the Linux kernel's crypto/ccp driver, which provides cryptographic acceleration for AMD platforms. A developer annotated a local pointer variable with the GCC/Clang __cleanup(kfree) attribute, intending the allocated buffer to be freed automatically when the variable left scope. The __cleanup attribute, however, invokes the cleanup function with the address of the annotated variable, not the variable's value. The cleanup handler therefore receives a pointer to a stack location rather than the heap address returned by kmalloc.

When kfree is called on that stack address, the kernel slab allocator dereferences memory that was never allocated through its allocator interfaces. This produces a crash, manifesting as a kernel oops or panic depending on configuration. The correct kernel idiom is the __free(kfree) macro, which expands to a wrapper that dereferences the local variable first and passes the heap pointer to kfree.

Root Cause

The root cause is API misuse classified as a Kernel Vulnerability and Improper Resource Cleanup. __cleanup(kfree) provides the address of a local variable to the cleanup callback. kfree expects a heap pointer. The mismatch silently typechecks because kfree accepts void *, which is assignment-compatible with any pointer type including struct { ... } **. No compiler warning was emitted, allowing the defect to land in mainline.

Attack Vector

A local actor or workload that triggers the affected CCP code path can induce the invalid kfree call and crash the kernel. The crash occurs deterministically when the cleanup runs, so any execution path that reaches the annotated scope is sufficient. Exploitation does not require crafted input beyond reaching the vulnerable function. No remote vector or privilege escalation primitive has been published, and the EPSS score reflects a low likelihood of opportunistic exploitation.

No verified public proof-of-concept code is associated with this CVE. The vulnerability mechanism — passing a stack address to kfree via misused __cleanup semantics — is fully described in the upstream commit messages referenced below.

Detection Methods for CVE-2026-45959

Indicators of Compromise

Kernel oops or panic logs referencing kfree, the slab allocator, or the ccp driver in the call trace
dmesg entries showing BUG: unable to handle or invalid kernel pointer originating from ccp_* functions
Unexpected reboots on AMD systems shortly after cryptographic workloads or ccp driver initialization

Detection Strategies

Audit kernel source for __cleanup(kfree) annotations and confirm replacement with __free(kfree) against the upstream patches
Compare running kernel build identifiers against fixed stable kernel commits 90f9090e3e74, 9a3ace9b010f, and d5abcc33ee76
Correlate host crash telemetry with CCP driver load events and cryptographic API usage

Monitoring Recommendations

Collect /var/log/kern.log and journalctl -k output centrally to detect repeated panics tied to the ccp module
Track kernel package versions across the fleet and flag hosts running unpatched stable branches
Monitor reliability metrics on AMD-based servers using kernel crypto offload to identify regressions consistent with this defect

How to Mitigate CVE-2026-45959

Immediate Actions Required

Apply the upstream stable kernel updates that replace __cleanup(kfree) with __free(kfree) in the CCP driver
Rebuild and redeploy any custom kernels that pulled the affected change, ensuring the fix commits are included
Restart hosts after patching so the corrected ccp module is loaded

Patch Information

The issue is resolved by the following upstream commits: Kernel Commit 90f9090, Kernel Commit 9a3ace9, and Kernel Commit d5abcc3. The patches change the annotation from __cleanup(kfree) to the kernel's standard __free(kfree) macro so that the heap pointer, not the stack address, is passed to kfree. Consume these fixes through your distribution's kernel update channel.

Workarounds

Blacklist the ccp module on systems that do not require AMD cryptographic acceleration to avoid loading the vulnerable code path
Disable workloads that exercise the affected CCP code path until the patched kernel is deployed
Where module removal is not feasible, prioritize patch rollout on AMD hosts performing kernel-side crypto offload

bash

# Verify kernel includes the fix commits and blacklist ccp if required
uname -r
grep -E 'ccp' /proc/modules
echo 'blacklist ccp' | sudo tee /etc/modprobe.d/blacklist-ccp.conf
sudo update-initramfs -u