CVE-2026-53016

What it actually does

This is a Linux kernel memory-corruption flaw in the CCP crypto driver handling AES RFC3686 CTR mode through AF_ALG/skcipher. Requests for rfc3686-ctr-aes-ccp use an 8-byte IV, but the completion path restored 16 bytes, causing an out-of-bounds write past the caller-provided IV buffer. In practical terms, a local process able to reach the affected crypto algorithm can trigger kernel memory corruption, which may lead to kernel crashes and, depending on memory layout and exploit reliability, could potentially be developed into local privilege escalation.

Why it matters to the business

Systems using affected Linux kernels with the CCP crypto driver exposed may be at risk of local denial of service and possible privilege escalation. The current public exploitation signal is low: EPSS is 0.0014, the vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no mature public exploit is indicated. Even so, kernel memory-corruption issues should be prioritized for routine kernel patching because successful exploitation can affect system availability and host integrity.

How an attack unfolds

An attacker first needs local code execution or the ability to run a process that can access the Linux AF_ALG crypto interface on a host using the affected CCP-backed AES implementation. The attacker opens AF_ALG/skcipher sockets and selects the affected RFC3686 CTR AES algorithm handled by the CCP driver. By submitting crafted encryption or decryption operations with the expected 8-byte IV, the vulnerable completion routine later copies 16 bytes back into the caller IV buffer. This overwrites adjacent kernel memory. A simple exploit path would attempt to crash the kernel, while a more advanced exploit would try to shape surrounding allocations so the overwrite corrupts useful kernel data and escalates privileges. No public mature exploit is currently indicated.

How to fix it

Apply the vendor kernel update that includes the fix changing the IV copy length from AES_BLOCK_SIZE to crypto_skcipher_ivsize(). Because no exact product or package fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or upstream-stable kernel branch once available. Where immediate patching is not possible, consider temporary mitigations: unload or blacklist the affected CCP crypto driver if it is not required, disable or restrict use of AF_ALG/skcipher modules where operationally feasible, and limit local shell/container access on systems that must remain unpatched. Test mitigations carefully because crypto drivers may be used by IPsec, storage encryption, TLS offload, or other workloads.

How to confirm the fix worked

Confirm the running kernel includes the patch titled 'crypto: ccp - copy IV using skcipher ivsize' or an equivalent distro backport. Validate through package changelogs, vendor advisories, or source inspection that the CCP AES completion path copies crypto_skcipher_ivsize() bytes rather than AES_BLOCK_SIZE bytes into the IV buffer. On running systems, check whether the CCP driver and AF_ALG/skcipher components are loaded and whether CCP-backed AES algorithms are registered in /proc/crypto. After remediation, reboot into the patched kernel and verify that the old vulnerable kernel is not still selected by the bootloader.

Typical attack path

1. Obtain local code execution on a Linux system running an affected kernel with the CCP crypto driver available.
2. Check whether AF_ALG/skcipher support and the CCP-backed RFC3686 CTR AES algorithm are accessible.
3. Create AF_ALG sockets and bind to the affected rfc3686 CTR AES skcipher implementation.
4. Submit crypto operations using the 8-byte IV expected by RFC3686.
5. Trigger completion in the CCP AES path, causing a 16-byte IV restore into an 8-byte buffer.
6. Use the resulting kernel memory corruption to cause a denial of service or attempt privilege escalation.

How to detect it

There are no known exploit-specific network indicators for this issue because exploitation is local and occurs inside the kernel crypto API. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and hypervisor/host availability records for unexplained kernel oopses, panics, KASAN reports, or general protection faults involving the CCP crypto driver, AF_ALG, algif_skcipher, skcipher, or rfc3686 CTR AES. Correlate crashes with local process execution, container activity, newly introduced binaries, fuzzing tools, or unusual use of AF_ALG sockets. If kernel crash dumps are available, inspect stack traces for ccp_aes_complete or related CCP AES completion functions and look for slab or stack out-of-bounds writes near IV buffer handling. Because normal cryptographic workloads may also use these components, prioritize events that coincide with crashes, privilege-boundary changes, suspicious local binaries, or repeated triggering attempts.

• ccp_aes_complete
• rfc3686(ctr(aes))
• rfc3686-ctr-aes-ccp
• algif_skcipher
• AF_ALG
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: stack-out-of-bounds
• general protection fault
• kernel BUG
• kernel panic
• ccp_crypto
• ccp

What your security team should do

• Prioritize patching affected Linux kernels during the next standard kernel maintenance window; accelerate for multi-user systems, container hosts, build servers, bastion hosts, and other systems where untrusted local code may run.
• Inventory systems with AMD CCP/CCP crypto driver support and AF_ALG/skcipher exposure by checking loaded modules and /proc/crypto.
• If patching is delayed, evaluate blacklisting or unloading CCP-related crypto modules and restricting local user access to high-value hosts.
• Monitor kernel logs for crashes, KASAN reports, or oops traces involving CCP AES completion, AF_ALG, algif_skcipher, or rfc3686 CTR AES operations.
• Ensure patched kernels are actually booted after update; removing vulnerable packages is insufficient if systems continue running an old kernel.
• Treat unexplained kernel panics on affected systems as potentially security-relevant and preserve logs, crash dumps, and workload context for investigation.