CVE-2026-31697: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-31697 Overview

CVE-2026-31697 is an out-of-bounds read vulnerability [CWE-787] in the Linux kernel's AMD Cryptographic Coprocessor (CCP) driver. The flaw resides in the Secure Encrypted Virtualization (SEV) ioctl handler sev_ioctl_do_get_id2() in drivers/crypto/ccp/sev-dev.c. When userspace requests the CPU ID through the Platform Security Processor (PSP) and the firmware command fails with an invalid length error, the driver still attempts to copy the firmware-required number of bytes to userspace. This overflows the kernel-allocated buffer and leaks adjacent kernel memory to the calling process.

Critical Impact

A local user with access to the SEV device can trigger a kernel slab out-of-bounds read, leaking up to 64 bytes of kernel heap data per call and potentially destabilizing the system.

Affected Products

• Linux Kernel (mainline) prior to the fixing commits
• Linux Kernel 7.1-rc1 and 7.1-rc2
• Distributions shipping AMD CCP/SEV drivers on EPYC platforms

Discovery Timeline

• 2026-05-01 - CVE-2026-31697 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-31697

Vulnerability Analysis

The defect lives in sev_ioctl_do_get_id2(), which services the SEV_GET_ID2 ioctl on AMD platforms exposing the PSP via /dev/sev. The handler allocates a kernel buffer sized according to the userspace-supplied length, then issues a firmware command through __sev_do_cmd_locked() to retrieve the CPU ID blob.

When the firmware reports SEV_RET_INVALID_LEN because the userspace buffer was too small, the driver previously fell through to copy_to_user() and attempted to write the number of bytes the firmware reported it required, not the bytes actually populated in the kernel buffer. KASAN flagged this as a 64-byte slab-out-of-bounds read at _copy_to_user+0x66/0xa0, exposing uninitialized slab content to userspace.

The fix skips the copy when the PSP command fails and adds a WARN if the driver returns success while the firmware error code indicates failure, since __sev_do_cmd_locked() is expected to return -EIO on any firmware error.

Root Cause

The handler trusted a firmware-supplied length value to drive a copy-to-user operation without validating that the kernel buffer was actually populated to that length. Combined with missing error-path handling on SEV_RET_INVALID_LEN, this produced a classic out-of-bounds read across slab boundaries.

Attack Vector

Exploitation requires local access and the ability to open /dev/sev and issue ioctls. An attacker invokes SEV_GET_ID2 with an undersized buffer to force the firmware to return an invalid-length error, then reads the leaked kernel slab data returned in the userspace buffer. Repeated invocations can be used to harvest sensitive kernel memory contents adjacent to the allocation.

No verified public exploit code is available. The vulnerability mechanism is documented in the kernel KASAN report and the corresponding stable patches.

Detection Methods for CVE-2026-31697

Indicators of Compromise

• KASAN reports referencing sev_ioctl_do_get_id2 and _copy_to_user in kernel logs
• Unexpected WARN traces from the CCP/SEV driver after the patch is applied, indicating drivers returning success on firmware errors
• Processes repeatedly issuing SEV_GET_ID2 ioctls against /dev/sev with small buffer lengths

Detection Strategies

• Audit kernel logs (dmesg, journalctl -k) for slab-out-of-bounds entries originating in drivers/crypto/ccp/sev-dev.c
• Enable Linux audit rules on /dev/sev open and ioctl syscalls to baseline legitimate SEV tooling
• Use eBPF tracing to capture ioctl numbers issued against the SEV character device by non-virtualization workloads

Monitoring Recommendations

• Alert on unprivileged or non-libvirt processes accessing /dev/sev
• Track frequency of SEV_GET_ID2 calls per process to detect brute-force memory leak attempts
• Forward kernel KASAN and WARN events to centralized logging for correlation across hosts

How to Mitigate CVE-2026-31697

Immediate Actions Required

• Apply the upstream stable kernel patches referenced below and reboot affected hosts
• Restrict access to /dev/sev to trusted virtualization components only via udev rules and group permissions
• Inventory AMD EPYC hosts running SEV-enabled workloads and prioritize them for patching

Patch Information

The fix has been merged to stable trees through the following commits: 06f06d8, 09427bc, 1fbac04, 2937f17, and 4f685db. The patch ensures copy_to_user() is bypassed whenever __sev_do_cmd_locked() reports a firmware failure.

Workarounds

• Remove or blacklist the ccp kernel module on hosts that do not require AMD SEV functionality
• Tighten permissions on /dev/sev so that only the virtualization service account can issue ioctls
• Disable SEV firmware features in BIOS/UEFI on systems where confidential VMs are not used

# Restrict access to the SEV device until patched kernels are deployed
sudo chown root:kvm /dev/sev
sudo chmod 0660 /dev/sev

# Optionally prevent the ccp module from loading on non-SEV hosts
echo 'blacklist ccp' | sudo tee /etc/modprobe.d/blacklist-ccp.conf
sudo update-initramfs -u