GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux KVM - CPU soft lockup setting per-page memory attributes on large SNP guests: Running an SEV-SNP guest

CVE-2025-38506Kernel, userspace & hypervisorcurated

Impact

Running an SEV-SNP guest with a large memory footprint - 1TB and up, which is exactly the shape of an AI training VM - drives the host into CPU soft lockups while KVM walks per-page memory attributes without rescheduling. The host stalls, the watchdog fires, and co-resident workloads suffer. A tenant does not need to attack anything: simply asking for a big confidential VM is enough.

Who can reach it

Triggered by a guest with a very large memory allocation. Tenant-reachable through normal VM sizing, which makes it as much a capacity-planning hazard as a security one.

What to do

Fixed in the Linux kernel - KVM/x86 SEV code or the ccp/PSP driver. Take the distro kernel update (RHEL/Rocky, Ubuntu, SLES) and **reboot the host**; SEV/SNP hypervisor paths cannot be live-patched in any meaningful way, and SNP platform init/shutdown is not safe to cycle under running guests. Drain confidential-VM tenants, reboot, then re-admit. No firmware, VBIOS or AGESA step needed, which makes this one of the cheaper classes of SEV fix to roll out. Directly relevant to AI hosts, where terabyte-class confidential VMs are the norm rather than the exception - do not dismiss this as a corner case on a GPU fleet.

References

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.