GPU VulnDB

Database/Kernel, userspace & hypervisor

Xen: inverted conditional disables the Zenbleed workaround on affected AMD CPUs and enables it elsewhere

CVSS 9.8CVE-2026-79608Kernel, userspace & hypervisorZenbleedcurated

Impact

A rework of the XSA-433 Zenbleed (CVE-2023-20593) workaround to better integrate with other manipulations of the same MSR introduced an inverted conditional, so the chicken bit is not set on the AMD Zen 2 parts that need it, and is set on parts that do not. The practical consequence is that Zenbleed is unmitigated again on affected hosts: a guest can read register contents left behind by other contexts, which on a Xen host running GPU tenants means leakage of data belonging to other VMs on the same core. There is no new primitive here - the exposure is the old one, restored by a patch regression, which matters because an operator who already closed XSA-433 will believe they are covered.

Who can reach it

Any guest running on an affected AMD host; the Zenbleed primitive is local to the CPU core and requires only unprivileged code execution inside a VM. No management-network or host access needed.

What to do

Apply the Xen patch from XSA-515 and reboot the hypervisor, which means draining and rebooting each affected host - expensive on GPU nodes with long-running training jobs, so plan the rolling window. Confirm the Zenbleed chicken bit is actually set on your AMD Zen 2 hosts after the update rather than assuming XSA-433 is still in force. Check which Xen versions in your fleet carry the reworked code; the advisory is the authority on affected ranges.

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.