Xen varstored (Xapi UEFI variable service, OVMF shared buffer): varstored runs in the host's control domain and

CVSS 9.4CVE-2025-58151Kernel, userspace & hypervisorcurated

Impact

varstored runs in the host's control domain and services UEFI variable requests from OVMF inside a guest through a shared buffer. Without compiler barriers, values are re-read after validation, so a guest can change them between check and use; in a default build the attacker ends up controlling an index into a jump table. That is a guest-to-host control-flow primitive in a process that sits outside the VM, scored 9.4 by the Xen project, and on a Xapi/XenServer host every other tenant VM on the box shares that control domain. Recovering means taking the host out of service, and a GPU host with passthrough devices cannot be live-migrated away cheaply.

Who can reach it

Any guest VM that boots with UEFI firmware (OVMF) on a Xapi/XenServer host - no host credentials and no authentication beyond controlling your own VM's firmware-facing code.

What to do

Apply the patched varstored from XSA-478 for your XenServer/XCP-ng version and restart the service; VMs must be restarted for a new varstored process to service them, so in practice plan a rolling drain and reboot of affected hosts. Exact behaviour depends on the compiler used to build varstored - rebuild from the patched source if you package it yourself.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-58151 https://xenbits.xen.org/xsa/advisory-478.html http://www.openwall.com/lists/oss-security/2026/01/27/2

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.