Linux kernel AMD CCP driver: kfree on a stack address crashes the kernel

CVSS 7.8CVE-2026-45959Kernel, userspace & hypervisorcurated

Impact

The AMD Cryptographic Coprocessor driver annotated a local pointer with __cleanup(kfree) instead of __free(kfree), so the address of the stack variable - not the heap pointer returned by kmalloc - was handed to kfree. Freeing a stack address is an invalid deallocation that crashes the kernel, and on the slab allocator a corrupted free can be worse than a clean panic. The ccp driver loads on every AMD EPYC host, including the ones backing SEV-SNP confidential GPU tenants, so the blast radius is the whole node and every pod on it. NVD scores it 7.8 local with high confidentiality, integrity and availability impact, but the record supplies no exploitation detail beyond the invalid free - treat availability loss as the established consequence and anything further as unproven.

Who can reach it

Local. An authenticated local user or a process in a container that can drive the affected ccp code path; no network exposure and no remote trigger is described in the record.

What to do

Pick up the fixed stable kernel from your distribution and reboot. There is no module-level workaround short of unloading ccp, which is not practical on AMD hosts that rely on the Secure Processor. Budget a drain and reboot per AMD node; GPU nodes mid-training are the expensive part, so fold this into the next scheduled kernel window unless you have reason to believe the path is being hit.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-45959 https://git.kernel.org/stable/c/90f9090e3e744a8fe3bb6fa0e61f577347728b0b https://git.kernel.org/stable/c/9a3ace9b010ffd8c422c97844ae152f7c53d6b18 https://git.kernel.org/stable/c/d5abcc33ee76bc26d58b39dc1a097e43a99dd438

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.