GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux KVM SVM: SEV ioctls return uninitialized kernel slab memory to the caller

CVSS 7.1CVE-2022-49556Kernel, userspace & hypervisorcurated

Impact

Several SEV ioctl handlers allocated the caller-supplied length with kmalloc, up to SEV_FW_BLOB_MAX_SIZE, but the PSP firmware writes only as much as it actually has. The unwritten tail is returned to userspace, leaking uninitialized kernel slab contents - potentially data from other allocations, including other tenants' structures on a shared host. The fix is to use kzalloc. This matters on AMD EPYC GPU hosts that use SEV/SEV-SNP for confidential VMs, since the leak undermines the isolation the feature is there to provide. It is an information leak only; no code execution or guest escape is claimed.

Who can reach it

A local user on the host with access to the SEV ioctl interface (typically /dev/sev or a KVM control path), i.e. the virtualization management plane rather than an arbitrary tenant. Requires low privilege but local access; not reachable from a guest or over the network.

What to do

Take the stable kernel fix (five backport commits are listed for the affected branches) via your distribution's kernel update, then reboot each host - a kernel change on a hypervisor means draining the GPU node and rebooting it. Only hosts with AMD SEV enabled are affected; hosts that never expose the SEV ioctls can defer to a normal maintenance window.

References

Related entries

All Kernel, userspace & hypervisor entries

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.