CVE-2026-31698

What it actually does

This is a Linux kernel memory safety flaw in the AMD Secure Encrypted Virtualization / Platform Security Processor crypto driver path for exporting a PDH certificate. If the PSP firmware command fails because the caller supplied an undersized userspace buffer, the vulnerable kernel path can still attempt to copy the firmware-reported length back to userspace. Because that length can exceed the kernel-allocated buffer, the kernel performs an out-of-bounds read from slab memory during copy_to_user(). The primary technical consequence is disclosure of kernel memory to a local userspace process; depending on kernel hardening, diagnostics, and runtime conditions, repeated triggering may also cause kernel warnings, crashes, or denial of service.

Why it matters to the business

Systems running affected Linux kernels with the AMD CCP/SEV device exposed may allow a local user or already-compromised process to read sensitive kernel memory or destabilize the host. On virtualization platforms using AMD SEV-related functionality, the impact is more operationally significant because the vulnerable code is in a host kernel driver associated with hardware-backed guest security. The issue is not currently listed in CISA KEV, has no known ransomware association, and has a low, stable EPSS score, but the CVSS impact remains material because exploitation can expose confidential host memory and potentially affect host availability.

How an attack unfolds

An attacker first needs local code execution on a vulnerable Linux system and access to the SEV/CCP device interface, commonly through the kernel ioctl path used by the SEV driver. The attacker opens the relevant device and issues a PDH certificate export request with buffer sizing that causes the PSP firmware command to fail due to an invalid or insufficient length. In the vulnerable implementation, the driver may continue into the userspace copy path using the firmware-required size rather than the size of the kernel buffer that was actually allocated. This results in the kernel copying bytes beyond the intended slab allocation into the attacker-controlled userspace buffer. The attacker can repeat the operation to sample leaked kernel memory, potentially recovering sensitive data or memory layout information useful for follow-on local privilege-escalation work. On systems with memory debugging or strict hardening, the same path may generate kernel warnings or trigger a crash instead of silently leaking data.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix for the AMD CCP/SEV PDH export error-handling path. The fix prevents the driver from copying PDH certificate blobs to userspace when the PSP firmware command fails, including invalid-length failures. No exact fixed package versions were provided in the input, so remediation should be tracked through distribution advisories and kernel changelogs for the relevant stable kernel streams. Where immediate patching is not possible, reduce exposure by restricting access to the SEV/CCP device nodes to only trusted administrative or virtualization-management components, removing untrusted local shell access, enforcing least-privilege group membership for device access, and disabling unused SEV/PSP functionality or the affected driver only where operationally safe. Because this is a kernel issue, reboot into the fixed kernel after installation; merely installing updated packages is insufficient if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, contains the vendor fix. Validate with uname -a, package-manager kernel version checks, and vendor advisory mapping for the affected distribution. Check whether the AMD CCP/SEV driver is present or loaded using lsmod, modinfo, dmesg, and the existence and permissions of /dev/sev or related CCP/SEV device nodes. Confirm that untrusted users cannot open the SEV device interface. After patching and rebooting, verify that the active kernel version matches the fixed build and that regression testing of SEV-dependent workloads succeeds. If safe in a controlled test environment, a vendor-supplied reproducer or kernel selftest should no longer produce KASAN slab-out-of-bounds reports or warnings in sev_ioctl_do_pdh_export.

Typical attack path

1. Gain local execution on an affected Linux host, container host, or virtualization server.
2. Confirm the AMD CCP/SEV kernel driver is loaded and that the process can access the SEV ioctl device interface.
3. Open the SEV device, such as /dev/sev where present and permitted.
4. Submit a PDH certificate export ioctl request with deliberately insufficient userspace buffer length.
5. Cause the PSP firmware command to fail with an invalid-length condition while the vulnerable driver still proceeds to copy data to userspace.
6. Receive out-of-bounds kernel slab memory bytes in the userspace buffer, or trigger a kernel warning/crash depending on hardening.
7. Repeat requests to collect additional leaked memory or to induce service instability.

How to detect it

Retrospective detection is difficult because successful exploitation may look like ordinary local ioctl activity unless detailed audit or eBPF telemetry is enabled. Review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for slab out-of-bounds reads, usercopy failures, WARN splats, or crashes involving the AMD CCP/SEV driver and the sev_ioctl_do_pdh_export call path. On systems with auditd or endpoint telemetry, look for processes opening /dev/sev followed by ioctl-heavy activity, especially from unexpected users, shells, test binaries, fuzzers, containers, or workloads that do not normally manage SEV certificates. If KASAN or hardened usercopy is enabled, exploitation attempts may leave explicit BUG/WARN records. Also review local privilege boundaries: unexpected access to SEV device nodes, abnormal group membership granting hardware device access, or repeated failures around PDH export operations should be investigated. No public threat actor exploitation is identified from the provided data, so detections should focus on local abuse patterns and kernel artifacts rather than named-campaign infrastructure.

• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in instrument_copy_to_user
• slab-out-of-bounds in _copy_to_user
• sev_ioctl_do_pdh_export
• drivers/crypto/ccp/sev-dev.c
• sev_ioctl
• __do_sys_ioctl
• copy_to_user
• Read of size 2084
• /dev/sev
• crypto: ccp
• PDH cert
• PSP command failed
• firmware error code
• __sev_do_cmd_locked
• WARN if the driver says the command succeeded

What your security team should do

• Prioritize patching internet-facing, multi-user, shared compute, virtualization, and AMD SEV-capable Linux hosts even though known exploitation and KEV status are currently negative.
• Inventory Linux systems with AMD CCP/SEV support enabled and identify where /dev/sev or equivalent device interfaces are accessible to non-root or service accounts.
• Restrict permissions on SEV/CCP device nodes to the minimum set of trusted administrative or virtualization processes until fixed kernels are deployed.
• Search kernel logs for KASAN, usercopy, or SEV ioctl warnings that match this vulnerability’s call path, especially on systems where local users or tenants can execute code.
• Ensure updated kernels are actually booted after patch deployment and remove or de-prioritize vulnerable kernels from boot menus where practical.
• Monitor vendor advisories for exact fixed versions for each deployed distribution and kernel stream, since fixed versions were not specified in the provided data.
• Treat any confirmed memory disclosure from a shared virtualization host as a potential sensitive-data exposure and follow incident-response procedures for host memory compromise.