CVE-2026-31699

What it actually does

This is a local Linux kernel vulnerability in the AMD Secure Encrypted Virtualization/Platform Security Processor crypto driver path used to retrieve a PEK CSR. If the firmware command fails because the user-provided buffer length is invalid or too small, the driver can still attempt to copy the firmware-reported length back to userspace. That length can exceed the kernel buffer that was actually allocated, causing an out-of-bounds kernel heap read during copy_to_user(). The practical impact is kernel memory disclosure to a local user with access to the SEV/PSP ioctl interface, and potentially a kernel warning, crash, or denial of service depending on kernel hardening, allocator state, and debugging options such as KASAN.

Why it matters to the business

Systems using affected Linux kernels with AMD SEV/PSP/CCP functionality exposed may allow a local user or compromised workload account to read sensitive kernel memory or destabilize the host. The highest-risk environments are virtualization hosts, cloud platforms, and systems where untrusted or semi-trusted users can access SEV-related device interfaces. This issue is not currently listed in CISA KEV, has no known mature public exploit in the provided data, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, kernel memory disclosure on shared infrastructure can still have high confidentiality consequences.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system and sufficient permission to open the AMD SEV/PSP device interface used by the crypto CCP driver. The attacker issues the SEV ioctl path for retrieving the PEK CSR while supplying a buffer and length combination that causes the PSP firmware command to fail, specifically in a way that reports a required length larger than the kernel buffer allocated by the driver. Due to the vulnerable error handling, the kernel proceeds to copy the firmware-reported number of bytes to userspace even though the command failed. The copy operation reads beyond the allocated kernel buffer and returns adjacent kernel heap contents to the attacker, or triggers a kernel diagnostic/crash if memory safety instrumentation detects the over-read. Repeating the operation may allow the attacker to collect fragments of kernel memory that could contain sensitive data useful for further local exploitation or defense bypass.

How to fix it

Apply a kernel update from the relevant Linux distribution or kernel vendor that includes the fix for the CCP/SEV PEK CSR error-handling bug. No exact fixed package versions were provided in the input, so track vendor advisories for the installed kernel stream and upgrade to the first release that explicitly includes the upstream fix described as not copying the CSR blob to userspace when the PSP firmware command fails. Where immediate patching is not possible, reduce exposure by restricting access to SEV/PSP device nodes such as /dev/sev and related PSP interfaces to only trusted administrative or virtualization service accounts, removing untrusted users from groups that can access those devices, and disabling AMD SEV/CCP functionality or unloading/blocklisting the relevant driver modules only if the platform does not require them. Because this is a kernel flaw, container isolation alone should not be treated as a complete mitigation if containers can reach the vulnerable device interface.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed build, not merely that an updated package is installed on disk; reboot if required and verify with uname -a and the distribution package manager. Review the vendor kernel changelog or source package for the CCP/SEV fix that prevents copying PEK CSR data to userspace after a PSP firmware command failure. Validate exposure by checking whether AMD SEV/PSP device nodes exist and which users or groups can access them, for example by reviewing permissions on /dev/sev and related PSP devices. On systems where access should be restricted, confirm only trusted service accounts can open the device. If feasible in a controlled test environment, run vendor or kernel self-tests that exercise SEV ioctl handling and confirm no KASAN, WARN, BUG, or slab-out-of-bounds messages are generated.

Typical attack path

1. Gain local execution on a Linux system running an affected kernel with the AMD CCP/PSP/SEV driver available.
2. Determine whether SEV/PSP device nodes such as /dev/sev or related PSP interfaces are accessible to the attacker’s user or group.
3. Invoke the SEV ioctl path that retrieves the PEK CSR with a deliberately undersized userspace buffer or invalid length parameters.
4. Cause the PSP firmware command to fail while returning a larger required length.
5. Abuse the driver’s incorrect failure handling so it copies more bytes to userspace than were allocated in the kernel buffer.
6. Analyze returned data for leaked kernel heap contents, or trigger repeated attempts that may destabilize or crash the host.

How to detect it

Retrospective exploitation detection is difficult because the vulnerable action is a local ioctl and successful memory disclosure may not create a distinct application log entry. Start with kernel logs from journald, dmesg, syslog, crash dumps, and hypervisor host monitoring for evidence of slab-out-of-bounds reads, KASAN reports, kernel BUG/WARN messages, Oopses, or panics involving the CCP/SEV driver, sev_ioctl_do_pek_csr(), _copy_to_user(), or drivers/crypto/ccp/sev-dev.c. If auditd, eBPF telemetry, EDR, or syscall tracing was enabled, search for unusual access to /dev/sev or related PSP device nodes, especially by non-hypervisor processes, shells, compilers, fuzzers, temporary binaries, or workload user accounts. Correlate such activity with kernel warnings, host instability, process crashes, or suspicious local privilege-escalation attempts. Named threat actors and ransomware use were not provided, and the issue is not listed in KEV in the supplied data, so detection should focus on local misuse of the affected device interface rather than known campaign-specific infrastructure.

• /dev/sev
• /dev/psp
• 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/0xa0
• sev_ioctl_do_pek_csr
• sev_ioctl
• drivers/crypto/ccp/sev-dev.c
• __sev_do_cmd_locked
• PSP command failed
• PEK CSR
• SEV_PEK_CSR
• Read of size 2084
• copy_to_user ../include/linux/uaccess.h
• KASAN: slab-out-of-bounds in instrument_copy_to_user

What your security team should do

• Prioritize patching affected virtualization hosts and systems where local users, tenants, CI jobs, containers, or untrusted workloads may have access to AMD SEV/PSP device interfaces.
• Inventory Linux systems with AMD SEV/PSP/CCP support enabled and identify which expose /dev/sev or related PSP devices.
• Restrict device-node permissions immediately so only trusted administrative or hypervisor service accounts can issue SEV ioctls.
• Monitor kernel and system logs for KASAN, BUG, WARN, Oops, or panic messages referencing sev_ioctl_do_pek_csr, copy_to_user, or drivers/crypto/ccp/sev-dev.c.
• Review audit logs for unexpected processes opening or issuing ioctls against /dev/sev or PSP device nodes.
• Treat any confirmed kernel memory disclosure on shared virtualization infrastructure as a potential sensitive-data exposure and perform incident response accordingly.
• Track distribution advisories because exact fixed versions were not provided and kernel backport version numbers may differ across vendors.