# Xen XSA-478 (CVE-2025-58151): a TOCTOU flaw in varstored enables privilege escalation from the VM

- **Published on:** 2026-01-27
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/cve-2025-58151-xen-xsa-478-varstored-toctou

A TOCTOU race condition in varstored, the Xapi toolstack component that manages UEFI variables, lets an attacker with kernel-level access inside a VM run code and escalate privileges. Here is who is affected and how to mitigate it.

---

On 27 January 2026 the Xen Project published security advisory **XSA-478**, which fixes **CVE-2025-58151** in **varstored**. This is a **TOCTOU** (Time-of-Check-Time-of-Use) race condition that can allow an attacker with kernel-level access inside a virtual machine to escalate privileges and execute code outside it.

## What varstored is and where the problem lies

`varstored` is a component of the **Xapi toolstack** (the management stack used by Xen-based platforms such as XenServer/XCP-ng) responsible for managing the **UEFI variables** of virtual machines. To do this, varstored accesses a **shared memory buffer** with the guest.

The flaw stems from **insufficient compiler barriers** when accessing that shared buffer. Because the guest can modify the contents of memory between the moment varstored **checks** it and the moment it **uses** it (hence the TOCTOU name), race conditions are introduced. According to the advisory, depending on the code the compiler generates, an attacker may be able to **control jump table indices**, which opens the door to **arbitrary code execution within varstored**.

## Who is affected

The vulnerability affects **only deployments using the Xapi toolstack**, and according to the official advisory, **all versions of varstored** are vulnerable.

For the issue to be exploitable, these conditions must be met:

- The guest must be an **x86 HVM virtual machine** configured as a **UEFI VM** (that is, with `firmware=uefi` in the HVM boot parameters).
- **PV guests** and VMs configured with traditional **BIOS** are **not exploitable**.

It is important to stress that the attacker needs **kernel-level access inside the VM** to leverage the flaw. This is not an attack launched directly from outside the host: the scenario is one where an attacker already controls a UEFI guest and wants to break out toward the host toolstack.

## Severity and impact

The advisory classifies the impact as **privilege escalation**: an attacker controlling the VM kernel can **execute code within varstored**, which runs in the host context. This breaks the isolation expected between the virtual machine and the management infrastructure, which is especially serious in multi-tenant environments (multiple customers sharing hardware). In our incident list we have rated it **high severity**.

## Mitigation and patch

According to the Xen advisory, **there are no workarounds**: the only way to mitigate the vulnerability is to **apply the patch** released by the project (`xsa478.patch`). If you operate a Xapi-based platform (XenServer, XCP-ng or derivatives), the practical recommendations are:

- **Update varstored** as soon as your distribution or vendor publishes the fixed packages.
- In the meantime, **review which VMs use UEFI** and assess the trust level of whoever operates them, since the vector requires control of the guest kernel.
- Keep up with the rest of the Xen advisories from the same batch (XSA-477 and XSA-479 were published on the same date), which are best applied together.

This incident is a good reminder that virtualization security does not end at the hypervisor: the **toolstack** and auxiliary components such as varstored are also part of the attack surface, and a shared-memory synchronization flaw can be just as serious as a flaw in Xen itself.

## Source

- Official advisory: [Xen Security Advisory XSA-478 (CVE-2025-58151)](https://xenbits.xen.org/xsa/advisory-478.html)
- CVE details: [CVE-2025-58151 on NVD](https://nvd.nist.gov/vuln/detail/CVE-2025-58151)