CVE-2026-31697

What it actually does

This is a Linux kernel memory disclosure flaw in the AMD Secure Encrypted Virtualization / Platform Security Processor crypto driver path. A local user with access to the SEV ioctl interface can request the CPU/firmware ID using a userspace buffer length that causes the firmware command to fail. Prior to the fix, the driver could still attempt to copy the firmware-reported number of bytes back to userspace even though the kernel-allocated buffer was smaller, causing a slab out-of-bounds read. The primary impact is disclosure of kernel memory to a local user; depending on kernel configuration and runtime conditions, the invalid copy path may also trigger kernel diagnostics or instability.

Why it matters to the business

Systems running affected Linux kernels on platforms exposing the SEV/PSP crypto device may allow a low-privileged local user to read sensitive kernel memory or potentially destabilize the host. This is most relevant for virtualization hosts, cloud infrastructure, confidential-computing platforms, and multi-user Linux systems where untrusted local users, containers, or workloads may have access to the affected device interface. The issue is not listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, but it should still be prioritized on shared compute and virtualization hosts because local kernel memory disclosure can undermine isolation assumptions.

How an attack unfolds

An attacker first needs local execution on an affected Linux system and sufficient permission to open the SEV/PSP device interface, typically associated with the AMD CCP/SEV driver. The attacker then sends a crafted ioctl request to retrieve the platform or CPU ID, intentionally supplying a userspace buffer and length combination that causes the firmware command to fail due to an invalid or insufficient length. In the vulnerable code path, the kernel driver fails to stop after the firmware error and proceeds to copy the firmware-requested number of bytes to userspace. Because the kernel buffer is smaller than the requested copy size, the copy reads past the end of the allocated slab object and returns adjacent kernel memory to the attacker. Repeated calls may allow the attacker to sample kernel memory contents, and on hardened or instrumented kernels the same condition may generate KASAN slab-out-of-bounds reports or other kernel warnings.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the upstream fix for the AMD CCP/SEV driver behavior: the driver must not copy the ID blob to userspace when the PSP firmware command fails. No exact fixed package versions were provided, so use the latest kernel security update from the operating system or appliance vendor and verify that the kernel includes the relevant `crypto: ccp` / `sev-dev` fix. Reboot into the patched kernel after installation. As interim mitigations, restrict access to SEV/PSP device nodes to only trusted administrative users, remove unnecessary user access to `/dev/sev` or related CCP devices, disable unused SEV functionality where operationally acceptable, and reduce local shell/container access on affected virtualization hosts. These mitigations reduce exploitability but do not replace patching.

How to confirm the fix worked

Confirm exposure by checking whether the system is running an affected kernel version and whether the AMD CCP/SEV driver and device interface are present. Validate remediation by confirming the host has booted into a kernel build containing the fix, not merely installed it. Review vendor advisories or kernel changelogs for the patch text indicating that the CCP/SEV code no longer attempts to copy the ID to userspace after a PSP command failure. On test systems, a regression test should verify that malformed SEV ID retrieval ioctl requests fail cleanly without returning extra bytes, producing KASAN findings, or logging slab-out-of-bounds reports. Also confirm that permissions on SEV/CCP device nodes prevent untrusted local users from opening them.

Typical attack path

1. Gain local code execution on a Linux system running an affected kernel.
2. Determine whether the AMD CCP/SEV device interface is present and accessible, such as via the SEV ioctl path.
3. Open the exposed device node and prepare a malformed SEV ID retrieval request with an undersized userspace buffer or invalid length.
4. Trigger the vulnerable ioctl path so the firmware command fails but the driver still attempts to copy the firmware-requested ID length.
5. Collect out-of-bounds kernel memory bytes returned to userspace or repeat the request to gather additional leaked data.
6. Optionally use the leaked kernel memory to support further local exploitation, bypass hardening assumptions, or investigate host secrets.

How to detect it

Look for evidence of local attempts to exercise the vulnerable SEV ioctl path. Useful telemetry includes kernel logs, `dmesg`, system journal entries, auditd records for device-node access, endpoint process telemetry, and crash/KASAN reports. Search for kernel messages referencing `slab-out-of-bounds`, `copy_to_user`, `sev_ioctl_do_get_id2`, `sev_ioctl`, `sev-dev.c`, or AMD CCP/SEV firmware command failures. Audit access to `/dev/sev` and related CCP/PSP device nodes by non-administrative users or unexpected processes. On hardened test or debug kernels, exploitation attempts may produce KASAN reports similar to the published trace, including `_copy_to_user` and `sev_ioctl_do_get_id2`. On production kernels without KASAN, exploitation may leave little or no direct artifact beyond device access patterns, kernel warnings, or crashes; absence of logs does not prove absence of exploitation.

• /dev/sev
• /dev/ccp
• sev_ioctl_do_get_id2
• sev_ioctl
• drivers/crypto/ccp/sev-dev.c
• crypto: ccp
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in _copy_to_user
• instrument_copy_to_user
• _inline_copy_to_user
• _copy_to_user+0x66
• copy_to_user
• Read of size 64
• PSP command failed
• firmware command failed
• invalid length
• __sev_do_cmd_locked
• SEV_GET_ID2

What your security team should do

• Prioritize patching shared Linux virtualization hosts, confidential-computing nodes, and systems where untrusted local users or workloads may have access to SEV/PSP interfaces.
• Inventory Linux systems with AMD SEV/PSP capability and identify those exposing `/dev/sev` or related CCP device nodes.
• Apply the latest vendor kernel security updates and reboot into the fixed kernel.
• Until patched, restrict device-node permissions for SEV/CCP interfaces to trusted administrators or required service accounts only.
• Review kernel logs for KASAN, slab out-of-bounds, `sev_ioctl`, or `sev_ioctl_do_get_id2` messages that may indicate attempted triggering or testing.
• Monitor for unexpected local processes opening SEV/CCP device nodes, especially from user shells, containers, build workers, or non-administrative accounts.
• Treat confirmed exploitation as a local kernel memory disclosure event and assess whether leaked memory could contain secrets, credentials, cryptographic material, or host isolation-sensitive data.