GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM x86: __get_sregs2() reads PDPTRs without SRCU protection, dereferencing memslots unsafely

CVSS 7.8CVE-2026-43214Kernel, userspace & hypervisorcurated

Impact

Reading PDPTR registers through the KVM_GET_SREGS2 ioctl can reach guest memory via load_pdptrs() and kvm_vcpu_gfn_to_memslot(), which requires kvm->srcu or slots_lock to be held; only vcpu->mutex was held, so the memslot pointer was dereferenced outside any read-side critical section. What is published is a lockdep splat found by syzkaller, not a demonstrated use-after-free - the practical risk is an unprotected memslot dereference racing a memslot update, which is a correctness and potential host-stability problem on a hypervisor node. For GPU clouds that rent VMs with passthrough GPUs this lives in the host hypervisor, where the attacker is a tenant that owns a VM, and a host crash takes every VM on that node with it. Do not read the 7.8 local score as a proven escape; the record supports an unsafe dereference, nothing more.

Who can reach it

Local, on the hypervisor host: any process holding an open KVM vCPU file descriptor (/dev/kvm), i.e. the VMM process for a tenant VM, calling the KVM_GET_SREGS2 ioctl. Not reachable from inside the guest directly and not reachable over the network.

What to do

Pick up the stable kernel with the added SRCU read-side protection (five branches carry it) and reboot the hypervisor; live-migrate or drain guests first, since KVM is built into the running kernel. No hot fix or runtime toggle exists. If you do not run KVM guests on GPU nodes, this is not actionable for you.

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.