GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM nSVM: userspace can trigger a kernel WARN by changing CPUID after loading CR3

CVSS 5.5CVE-2026-43315Kernel, userspace & hypervisorcurated

Impact

A process that can drive the KVM vCPU ioctls can make nested_svm_load_cr3() fail by setting CR3 and then shrinking the guest's MAXPHYADDR via CPUID, hitting a WARN in svm_set_nested_state(). On its own a WARN is log noise, but on hosts configured with panic_on_warn - common in fleets that want crash dumps for triage - it becomes a remote-from-the-guest-operator way to panic the AMD host, taking every co-tenant GPU workload on that node with it. It also lets an unprivileged local process spam the kernel log. The fix simply deletes the WARN; the underlying state was never a memory-safety problem.

Who can reach it

Local, requires access to /dev/kvm and the ability to call KVM_SET_SREGS / KVM_SET_CPUID / KVM_SET_NESTED_STATE on a vCPU. AMD hosts only (SVM). No network exposure.

What to do

Apply the stable kernel update that removes the WARN and reboot the affected AMD hosts. As an interim measure, if panic_on_warn is enabled on GPU hosts that expose /dev/kvm to tenants, turning it off removes the availability impact and leaves only log noise.

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.