Hello all,

Version 9.0.9137 Release Signed of the Windows PV drivers has been released.

Proudly presenting the first signed build of the XCP-ng Windows PV drivers since 8.2.2.200-RC1 was released over six years ago. This build can be installed as-is without further configuration.

Always download the latest release from https://github.com/xcp-ng/win-pv-drivers/releases !

To download XenClean, click here. The installer downloads also includes a copy of XenClean and XenBootFix. Remember to carefully read XenClean docs before use.

Before installing

Thank you for using our Windows PV drivers. Please carefully read the instructions below.

• Not compatible with the "Manage Citrix PV drivers via Windows Update" option. You must disable this option before installing.
• Make backups/snapshots before installing!

Known issues

• NIC RSS is not functional; fixes are under way.

Changes since 9.0.9136

• NEW: Digitally-signed drivers and installer.
• Fixes: Fix Xen Guest Agent version reporting.

Changes since 8.2.2-beta

• IMPORTANT: Security fix for XSA-468 (CVE-2025-27462, CVE-2025-27463, CVE-2025-27464). Check the XCP-ng docs or blog announcement for more details.

• This release is based on upstream 9.1-series drivers, which includes the PV Mouse/Keyboard driver and PV Console Driver. You can access the PV console with the following command from a XCP-ng host:

xl console -t pv <vmname>

• New installer with clean uninstallation and multiple install/uninstall safety checks.
• New XenClean utility for cleanly removing XCP-ng and Citrix drivers.
• Numerous driver stability fixes.
• Volume Shadow Service Provider is no longer included. (XCP-ng 8.1 and newer no longer support quiescent snapshots)
• Check out the new Rust-based Xen Guest Agent included in our package! We're looking to bring back even more features to the agent.
• Older Windows versions are no longer supported. The driver requires at a minimum Windows 10 1607 or Windows Server 2016.

Help / Community support

If you encounter installation/uninstallation errors, please try again with one of the following commands:

For installing:
msiexec.exe /i XenDrivers-x64.msi /log install.log

For uninstalling:
msiexec.exe /x XenDrivers-x64.msi /log uninstall.log

Please include this log along with the file C:\Windows\INF\setupapi.dev.log in your bug report. These files will help us troubleshoot any installation issues.

Additionally, please report any errors or BSOD you encounter during testing of this release. Your feedback is very appreciated.

• Discussion: https://xcp-ng.org/forum (preferred)
• Issue Tracker: https://github.com/xcp-ng/xcp/issues
• IRC: #xcp-ng and #xcp-ng-dev on irc.freenode.net

Full Changelog: https://github.com/xcp-ng/win-pv-drivers/compare/v9.0.9136...v9.0.9137

Hello,

We're glad to announce a new Alpha version 9.0.9000.0 of our XCP-ng Windows PV Drivers for Windows 10 1607 or newer, and Windows Server 2016 or newer. Note: this driver release is for testing purposes only. Not for production use!

The release includes new 9.1-series drivers from Xen Project with new features and stability improvements. We also included a XenClean tool for cleanly removing any existing Xen PV drivers, whether they are installed via XCP-ng, Citrix or Windows Update. Feel free to give it a try!

We're looking to finalize the drivers and produce a signed, Windows-ready installation package. Your feedback will help us greatly in reaching this goal.

You'll find the new release on XCP-ng GitHub. Below are the release notes:

Before Installing

• This driver release is for testing purposes only. Not for production use!
• Make backups/snapshots before installing!
• The drivers in this package are testsigned and require enabling testsigning mode. Disable Secure Boot, then run the included script testsign/install.ps1 as Administrator to configure Windows and install the necessary signer certificates. Your VM will reboot automatically.
• If you encounter installation/uninstallation errors, please try again with one of the following commands:

For installing:
msiexec.exe /i XenDrivers-x64.msi /l*vx install.log

For uninstalling:
msiexec.exe /x XenDrivers-x64.msi /l*vx uninstall.log

Please include this log along with the file C:\Windows\INF\setupapi.dev.log in your bug report. These files will help us troubleshoot any installation issues.

Changes since 8.2.2-beta

• This release is based on upstream 9.1-series drivers, which includes the PV Mouse/Keyboard driver and PV Console Driver. You can access the PV console with the following command from a XCP-ng host:

xl console -t pv <vmname>

• New installer with clean uninstallation and multiple install/uninstall safety checks.
• New XenClean utility for cleanly removing XCP-ng and Citrix drivers.
• Multiple driver stability fixes.
• Volume Shadow Service Provider is no longer included. (XCP-ng 8.1 and newer no longer support quiescent snapshots)
• Management Agent is currently not included. Xen Orchestra may show "Management agent not detected", but shutdown and reboot features will work normally. We're looking to bring back features of the management agent in the next releases.

Help / Community Support

Please report any errors or BSOD you encounter during testing of this release. Your feedback is very appreciated.

edit: Before using XenClean or XenBootFix, please read carefully the instructions on the XCP-ng documentation website!

Hello all,

Version 9.0.9030 of the new Windows PV drivers has been released.

This release brings multiple driver stability fixes, a new Rust-based Xen Guest Agent and the XenBootFix boot repair tool.

This driver release is for testing purposes only and not for production use. It requires putting the system into testsign mode. (only applies to the drivers themselves, not XenBootFix and XenClean; you can use the two tools separately without any configuration)

Download the release here: https://github.com/xcp-ng/win-pv-drivers/releases/tag/v9.0.9030

Release notes are below:

Before Installing

• This driver release is for testing purposes only. Not for production use!
• Make backups/snapshots before installing!
• The drivers in this package are testsigned and require enabling testsigning mode. Disable Secure Boot, then run the included script testsign/install.ps1 as Administrator to configure Windows and install the necessary signer certificates. Your VM will reboot automatically.
• If you're running version 9.0.9000.0, we're interested in hearing about your upgrade experience to 9.0.9030.

Changes since 9.0.9000.0

• NEW: Includes the new Rust-based Xen Guest Agent for resource and IP address reporting.
• NEW: Includes the new XenBootFix boot repair tool for VMs rendered unbootable by any Xen drivers (Xen PV, XCP-ng, Citrix, etc.)
• NOTICE: Xen PV disk drivers are now disabled by default on new installations. The default emulated NVMe driver will be used instead. Existing installations will not be affected.
• Fixes: Many more installation, uninstallation and upgrade safety checks are now built into the installer.
• Fixes: Various improvements to XenClean for more complete removal of driver services.
• Fixes: xenvbd: Xen PV disk drives now report as SSD drives to avoid unnecessary defragmentation (commit)
• Fixes: xenvif: Fix various VM hanging and crashing issues when changing VM network in Xen Orchestra (commit 1, commit 2)
• Debug symbols are now included with the installation package.

Changes since 8.2.2-beta

• This release is based on upstream 9.1-series drivers, which includes the PV Mouse/Keyboard driver and PV Console Driver. You can access the PV console with the following command from a XCP-ng host:

xl console -t pv <vmname>

• New installer with clean uninstallation and multiple install/uninstall safety checks.
• New XenClean utility for cleanly removing XCP-ng and Citrix drivers.
• Multiple driver stability fixes.
• Volume Shadow Service Provider is no longer included. (XCP-ng 8.1 and newer no longer support quiescent snapshots)
• Management Agent is currently not included. Xen Orchestra may show "Management agent not detected", but shutdown and reboot features will work normally. We're looking to bring back features of the management agent in the next releases. Check out the new Rust-based Xen Guest Agent included in our package! We're looking to bring back even more features to the agent.
• Older Windows versions are no longer supported. The driver requires at a minimum Windows 10 1607 or Windows Server 2016.

Help / Community Support

If you encounter installation/uninstallation errors, please try again with one of the following commands:

For installing:
msiexec.exe /i XenDrivers-x64.msi /l*vx install.log

For uninstalling:
msiexec.exe /x XenDrivers-x64.msi /l*vx uninstall.log

Please include this log along with the file C:\Windows\INF\setupapi.dev.log in your bug report. These files will help us troubleshoot any installation issues.

Additionally, please report any errors or BSOD you encounter during testing of this release. Your feedback is very appreciated.

• Discussion: https://xcp-ng.org/forum (preferred)
• Issue Tracker: https://github.com/xcp-ng/xcp/issues
• IRC: #xcp-ng and #xcp-ng-dev on irc.freenode.net

Full Changelog: https://github.com/xcp-ng/win-pv-drivers/compare/v9.0.9000.0...v9.0.9030

kernel-4.18.0-553.71.1.0.1.el8_10 (OL8) and kernel-5.14.0-570.37.1.0.1.el9_6 (OL9) do not contain the fix. kernel-6.12.0-55.29.1.0.1.el10_0 (OL10) does.

Hi all,

I've uploaded a version of the mitigation script Install-XSA468Workaround-Win7.ps1 with unofficial support for down to Windows 7/2008R2 and 8/8.1/2012/2012R2.

Reminder: this is purely unofficial support and not tested on all listed OSes yet. The mitigation script itself is meant as a last resort only when you absolutely cannot update; it does not mitigate all vulnerabilities and it does not replace updating your drivers.

@Tristis-Oris @TrapoSAMA

XSA-468: multiple Windows PV driver vulnerabilities - update now!

Original announcement: https://xcp-ng.org/blog/2025/05/27/xsa-468-windows-pv-driver-vulnerabilities/.
Check the XCP-ng docs for the latest updates.

Summary

Multiple vulnerabilities have been discovered in all existing Xen PV drivers for Windows from all vendors (XCP-ng, XenServer, etc.) published prior to the disclosure, on May 2025.

These vulnerabilities allow unprivileged users to gain system privileges inside Windows guests.

These issues have the following identifiers:

• CVE-2025-27462
• CVE-2025-27463
• CVE-2025-27464

Am I affected?

Windows guests running vulnerable versions of Xen PV drivers are affected. Other guest OSes are not affected.

To check if you're affected, verify the version of Xen PV drivers in Device Manager.

Driver version numbers are independent from Xen PV tools package versions. Use the methods below to check the precise driver versions.

• XCP-ng PV Bus, XCP-ng Interface and XCP-ng PV Console older than 9.0.9065 are affected.
• XenServer/Citrix PV Bus older than 9.1.11.115; PV Interface older than 9.1.12.94 are affected.
• Other Xen PV drivers for Windows are also likely affected. If you are using these drivers, verify each vendor's security bulletins for more details.

You can check for this vulnerability from within the Windows VMs themselves (most precise, recommended) but also from outside the VMs, using tools we built for this purpose.

If you are reading this article shortly after its publication, it's likely that all of your Windows VMs are vulnerable.
Once patched, follow these instructions to verify that your VMs are no longer vulnerable.

Check a Windows VM for vulnerability

This is the most precise way, but needs to be done per VM.

• Verify the version numbers in Device Manager.
• Use the mitigation script published in the XSA-468 advisory in -Scan mode (will only report the vulnerability, not version numbers). See the script for documentation.

Detect vulnerable VMs at the pool level

This method requires the latest XCP-ng updates to be applied, in XCP-ng 8.2 and 8.3.

We developed two features to help you with the handling of these vulnerabilities.

• A host-side detection script, that you can run in dom0. It will list affected Windows VMs based on their PV driver versions. See the script for documentation.
• A warning ️ sign next to affected VMs and a vulnerable? filter in Xen Orchestra. These features will be made available very soon, through an update to the stable channel. Keep an eye on the XCP-ng documentation for announcements.

This detection depends on XAPI accurately reporting PV driver versions. Prior to the recent XCP-ng 8.2 and 8.3 updates released in May 2025, this was not the case. As a result, the detection tools cannot assess VMs that have not been run since the updates were applied. If no driver information is available, a warning will be displayed.

️ Only virtual machines (VMs) created using a Windows template—or from templates or VMs originally derived from one—can be detected by these tools. They are designed to help users identify vulnerable VMs that may have been overlooked, forgotten during patching, or restored from backups taken before vulnerability fixes were applied. These tools are not intended to serve as comprehensive detection solutions, so do not rely on them exclusively.

How to patch my VMs?

First, create backups and snapshot your VMs before updating.

If you're using XenServer Windows PV drivers or have enabled the "Manage Citrix PV drivers via Windows Update" feature: Upgrade to XenServer VM Tools 9.4.1 or later.

If you're using XCP-ng Windows PV drivers 8.2.x, you should use XenClean to remove the existing drivers, then choose one of the following:

• On a production system, install XenServer VM Tools 9.4.1 or later;
• If you're not running a production system, and want to test the latest XCP-ng Windows PV drivers: install XCP-ng driver version 9.0.9065 or later. (Note that this requires bringing Windows into test signing mode)

If you're already using XCP-ng Windows PV drivers 9.0: Install XCP-ng driver version 9.0.9065 or later.

I can't patch now, what should I do?

You are encouraged to apply the latest updates as soon as possible.

If you absolutely cannot update, apply the mitigation script provided by Vates and the Xen Project, available at https://xenbits.xen.org/xsa/advisory-468.html.

Note that this mitigation script only covers vulnerabilities in the Xen PV Interface driver.

You should run the mitigation script in Scan mode afterwards to make sure the vulnerability is effectively mitigated.

How is Vates helping to address this vulnerability?

This issue was discovered by Vates as part of our investment into upstream Xen development. Vates VMS provides multiple facilities to help users affected this issue:

• We developed fixes for these vulnerabilities, which have been integrated upstream.
• We provided a mitigation script for those who cannot install the update.
• We have added detection logic in Xen Orchestra's latest release channel to actively alert on vulnerable Windows VMs. We also updated XCP-ng 8.2 and 8.3 so that PV driver versions are reported to Xen Orchestra for it to detect vulnerable Windows VMs. See "Am I affected?" above.
• We have developed a script that can be run in dom0 to perform the same detection, in case Xen Orchestra’s detection logic is not yet available to you. See "Am I affected?" above.
• We are publishing an alert about the vulnerability inside all Xen Orchestra appliances.
• We alert about this vulnerability at the beginning of our latest newsletter.

Why can't I use XCP-ng Windows PV drivers in production?

The XCP-ng 9.0 drivers aren't signed by Microsoft yet, and thus currently require putting Windows into test mode. As a result, these drivers are not appropriate for production use.

You may have noticed that the XCP-ng 8.2 Windows drivers can still be used when Secure Boot is disabled. This is due to these drivers being signed before Microsoft changed the driver signing rules and forcing 1st-party driver signatures.

We are actively working with Microsoft to get the drivers signed (which is a slow process). An announcement will be made as soon as a Microsoft-signed build is available.

Related links

• Xen Project announcement: https://xenbits.xen.org/xsa/advisory-468.html
• XenServer Security Bulletin: https://support.citrix.com/article/CTX692748

This is a driver bug that we fixed in XCP-ng Windows tools v9.0.9030 but hasn't been integrated by Citrix yet. You can try it out if you're not running a production system.

@plaidypus Hello, I'll change it to report the correct OS version (Windows 11 Professional 64-bit, Windows Server 2022 Datacenter 64-bit) in the next version. In fact, the change is already integrated in our code here: https://github.com/xcp-ng/xen-guest-agent/commit/004056c1d6f185077768678944558dd5df5fa45d

Hi all, here's a pre-build of the fix for anyone who wants to test (8.3 only):

wget https://koji.xcp-ng.org/repos/user/8/8.3/xcpng-users.repo -O /etc/yum.repos.d/xcpng-users.repo
yum update --enablerepo=xcp-ng-ndinh1

@manilx You can use the XenClean tool from our 9.0.9000 driver release: https://github.com/xcp-ng/win-pv-drivers/releases/tag/v9.0.9000.0

Just go into package\XenClean\x64 and run Invoke-XenClean.ps1 as admin, it will remove all existing drivers and automatically reboot.
Afterwards you can install the Citrix 9.4.0 tools.

Note: Please make sure to take a snapshot before running the tool.

@Chico008 said in XOA - Vm linux install keep failing since updateing XCP to 8.3:

tried using uefi (non secure) or bios, each time install failes.

ISOs comme from my NAS, and VM disk are hosted on a ISCSI Lun

on 8.2 was exactly the same conf, sources, all worked fine, but now i can't :/, and i'm unable to understand the report, i only it failed during kernel install.

my Isos are the same i used for 8.2, on the same NFS Share.

tried installing a win 2K19 server, seems ok, but Ubuntu server can't (even tried a ubuntu server 22, same)

Reply

Could you post the ISO version you were using for the installation and hardware details?

@acebmxer Could you fetch and send the error report somewhere?

@lastcmaster Hi, it's a known issue that guest agent versions are not reported after migration or suspend. Other functionalities (poweroff/reboot, suspend, network change etc.) should continue to work normally.

@flakpyro said in VM start stuck on "Guest has not initialized the display (yet).":

@dinhngtu said in VM start stuck on "Guest has not initialized the display (yet).":

You must run secureboot-certs clear if you're updating from 1.2.0-2.4 or 1.2.0-3.1 and have previously run secureboot-certs install with the above versions installed.

Should we run this before installing the update or after 1.2.0-3.2 has been installed?

You should run that preferably after updating all hosts.

@lukasz_s said in VM start stuck on "Guest has not initialized the display (yet).":

@dinhngtu thanks for advice

i've upgraded varstored and varstored-tools:

rpm -qa | grep varstored
varstored-1.2.0-3.2
varstored-tools-1.2.0-3.2

than i've cleared varstore with secureboot-certs clear
should taht folder contain more files ?

ls /usr/share/varstored/
KEK.uth
PK.auth
db.auth

what about dbx file ?

That file is not shipped with varstored nor needed for now. We're validating the final 1.2.0-3.2 and preparing our guidance for the official update.

@acebmxer All looks good from the output. There might be some VMs that need fixes for Windows dbx updates to work properly, I'll try to add that in the official version.

@acebmxer Yes, that'll fix the situation.

Note that we're discussing a different approach for the official update, which will involve using a manual repair tool.

@flakpyro said in XCP-ng 8.3 updates announcements and testing:

@dinhngtu The output of that command seems to result in the output of "Scanningn every UUID in my pool", most of which do not use SB. Im guessing that normal and i do not have any affected VMs any longer?

Yes, it'll produce an error message in unserialize_variables when there's a problem.

@acebmxer Scanning on 1 host will scan the whole pool at once.

In the output you posted, there's only c81f1f1b-9f95-38ec-f96e-5ce8fea073e6 which needs fixing.

@acebmxer You can confirm if there are other affected VMs using this command:

xe vm-list --minimal | xargs -d, -Ix sh -c "echo Scanning x 1>&2; varstore-ls x" > /dev/null

If there are still affected VMs, you must fix them on varstored-1.2.0-3.2 by secureboot-certs clear + propagating before downgrading to 2.3 (if you wish).

Note that downgrading to 2.3 with pool certs cleared means you'll need to set up guest Secure Boot again. So I recommend staying on 3.2 if it's possible for you.

@lukasz_s Thanks. As this is a test update, please take note of any issues especially with new Windows installations.

For reference, here are the prerelease notes:

• Both varstored and varstored-tools must be updated together.
• After the update, to ensure that the new varstored version is running, VMs must be migrated to an updated host (e.g. using RPU) or rebooted.
• You must run secureboot-certs clear if you're updating from 1.2.0-2.4 or 1.2.0-3.1 and have previously run secureboot-certs install with the above versions installed.
• If you are unsure, it's recommended to run secureboot-certs clear anyway.
• If you have already propagated UEFI certificates to your existing VMs following the varstored 1.2.0-3.1 update, it's recommended to update to 1.2.0-3.2 and propagate UEFI certificates again.

@Greg_E said in XCP-ng 8.3 updates announcements and testing:

@dinhngtu

I was just getting ready to go update my pool... So is it safe now? And do these certs only affect Secure Boot VMs or UEFI VMs as well?

This problem will affect UEFI VMs. See the announcement above for more details.

In short, if you haven't updated, you should be safe; the offending update has been withdrawn and no longer available from yum update (as long as you're not using the testing branch).

@acebmxer said in XCP-ng 8.3 updates announcements and testing:

@dinhngtu Thank you for that reply.

Just to clarify I have 4 host. 2 host i updated to latest update once they became available to public via pool updates. The other 2 host I had to push the second beta release to get command secureboot-certs install to work. Then I pushed the rest of the update again once they became public.

So far im only seeing 1 vm having the issue on the later 2 host the had the beta updates installed. There that test PC and 1 windows server (Printsrver), xoproxy, and xoce.

Should i run those commands on all 4 host or just the later 2 with the troubled vm?

I haven't tested using different versions of varstored within the same pool.