Linux kernel ccp driver: IV restore overruns the 8-byte RFC3686 IV buffer

Impact

For rfc3686(ctr(aes)) requests the skcipher IV is 8 bytes, but ccp_aes_complete() wrote back a full AES block (16 bytes), overrunning the caller's IV buffer. Reached through AF_ALG, this is an out-of-bounds write driven from an ordinary socket API. NVD rates it 7.8 local with full C/I/A, so treat it as a local privilege-escalation primitive rather than a cosmetic length bug. The AMD CCP is present on EPYC hosts, which is what sits under a large share of AMD and NVIDIA GPU nodes, and AF_ALG is reachable by unprivileged processes unless the fleet already restricts it - so the exposed party is any tenant with a shell or pod on the node.

Who can reach it

Local user able to open an AF_ALG socket and select the ccp-backed rfc3686-ctr-aes algorithm, on a host with an AMD CCP crypto device. Unprivileged by default; no remote path.

What to do

Update to a stable kernel carrying the fix and reboot the node - the change is in the driver's completion path, so nothing short of a new kernel closes it. Where a reboot cannot be scheduled yet, blocking the AF_ALG socket family (or the algif_skcipher module) for tenant workloads removes the reachable path. Reboots on GPU nodes mean draining jobs first.

References