GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM/arm64 nested virt: injected SError leaves ESR_EL2 stale for the guest hypervisor

UnscoredCVE-2026-80873Kernel, userspace & hypervisorcurated

Impact

kvm_inject_el2_exception() builds a syndrome for SError but only writes ESR_EL2 for synchronous exceptions, and enter_exception64() writes ESR_ELx for nothing, so the constructed syndrome is dropped. A guest L2 hypervisor taking a nested SError therefore reads whatever was left in ESR_EL2 from before, on both kvm_inject_nested_serror() and the EASE path of kvm_inject_nested_sea(). The consequence described is a guest making error-handling decisions on stale data - a misclassified or unhandled asynchronous abort inside a nested guest - not host compromise or a host escape. Scope is narrow and worth stating plainly: it only applies to arm64 hosts, such as Grace or Ampere class GPU nodes, that actually run KVM with nested virtualization enabled. On the far more common non-nested configuration the code path never executes.

Who can reach it

Exercised by a guest, not remotely: an L1 guest running its own hypervisor on an arm64 KVM host with nested virtualization enabled. Requires the ability to run a VM on the host; unreachable if NV is off, which is the default on most fleets.

What to do

Update to a stable kernel containing commit 09f35145, 29227821 or e2cb1f45 and reboot each arm64 host that runs nested virtualization; the record names no fixed release number. If nested virtualization is not a requirement for your workloads, leaving it disabled removes the exposure without a reboot.

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.