New maintenance update candidates for XCP-ng 8.3 LTS

This update is focused on security fixes.

What changed

• edk2:
  Sync with XenServer edk2-20220801-1.7.13. The update fixes vulnerabilities allowing an unauthenticated attacker on the local network to compromise a VM during PXE boot, or enable a guest VM administrator to bypass Secure Boot. See below the list of the corresponding CVEs:

  • CVE-2026-97631
  • CVE-2024-38796
  • CVE-2024-38797
  • CVE-2019-14560
  • CVE-2022-36763
  • CVE-2022-36764
  • CVE-2026-45447
  • CVE-2026-111497

Versions

• edk2: 20220801-1.7.11.2.xcpng8.3 -> 20220801-1.7.13.1.xcpng8.3

Test on XCP-ng 8.3

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot # not mandatory but recommended for testing

The usual update rules apply: pool coordinator first, etc.

What to test

As usual, normal use and anything else you want to test.

Additionally, a cold boot (shutdown and start) of the UEFI VMs would also help testing the edk2 fix.

Test window before official release of the updates

About 4 days

We would like to thank users who shared feedback since our last call for testing: @acebmxer, @jr-m4, @bufanda, @flakpyro, @Andrew, @MajorP93, @JeffBerntsen, @manilx, @XCP-ng-JustGreat, @john205, @Greg_E.

We are aware of the frequency of these updates and strive to batch packages as much as possible. However, recent unplanned security updates require immediate attention. While drafting this message, we received another security update that we will release shortly.

@acebmxer said:

applying the updates on hosts at work. So far 2 out of 3 pools updated succesfully. however when i go to attempt to apply updates on the last pool i see this...

@acebmxer, thanks for the feedback. We have no explanation at the moment. So far, all our tests have been successful. We may be missing a specific scenario that triggers this error.

Do you have any additional information in the host logs?

If not, could you export and send us a status report using xen-bugtool? One of our developers may be able to spot something that helps explain the issue.

@john205 said:

"apply the iptables-based mitigation described below"

Thanks for reporting the mistake. The mitigation is described in the VSA.

The blog is now fixed!

We have just released a security update for a critical Linux kernel vulnerability CVE-2026-98432 / VSA-2026-056.

Full details are available on the blog: https://xcp-ng.org/blog/2026/11/04/november-2026-security-updates-2-for-xcp-ng-8-3-lts/

Thank you everyone for your tests and your feedback!

The updates are live now.

Note that the update includes an additional kernel security update. Another vulnerability was disclosed recently, we will provide provide the update soon. Checkout the blog post for detailed information: https://xcp-ng.org/blog/2026/11/03/november-2026-security-and-maintenance-updates-1-for-xcp-ng-8-3-lts/

New xapi update in xcp-ng-testing for the next XCP-ng 8.3 LTS maintenance update

We've just published a new xapi package in the xcp-ng-testing repository:

xapi: 26.1.21-1.2.xcpng8.3 -> 26.1.21-1.3.xcpng8.3

It reverts an upstream commit (released to XCP-ng's testing as 26.1.21-1) that introduced a regression, which was found by Veeam. This package will be part of the official maintenance update that will be published as expected tomorrow.

Thanks again to all the testers who helped with this milestone.

New packages in xcp-ng-testing for the next XCP-ng 8.3 LTS maintenance update

This is a follow-up of the the previous post and addresses the issue reported by our testers.

First of all, a huge thanks to all testers who allowed us to catch this backup issue early:
@acebmxer, @jr-m4, @bufanda, @flakpyro, @Andrew.

We decided to revert the change that improves the performance of xapi-nbd since it caused the backup issue. This change will be reworked and refined, then presented to you again in a future update, without this issue. While investigating, we also found a bug in blktap: in rare cases, the process handling a VM disk (tapdisk) could crash during a backup and leave the disk impossible to detach. The new blktap version fixes it.

Versions

• blktap: 3.55.5-12.2.xcpng8.3 -> blktap-3.55.5-12.3.xcpng8.3
• xapi: 26.1.21-1.1.xcpng8.3 -> 26.1.21-1.2.xcpng8.3

Test on XCP-ng 8.3

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

If you reverted the previous candidates with yum history undo, update normally with the commands above. Note that downgrading is not recommended. If you disabled NBD in your backup jobs as a workaround, please enable it again after the update.

The usual update rules apply: pool coordinator first, etc.

What to test

If you have already carried out the initial updates and performed the tests mentioned in our previous post, please confirm that the XO backups are now back to a working state.

If you did not run the initial update and have not yet performed any tests, please be sure to review the "what to test" section of the the previous post.

Test window before official release of the updates

~7 days

New maintenance update candidates for XCP-ng 8.3 LTS

This batch of updates contains mostly fixes, tools version update, and some improvements.

What changed

Virtualization & System

• xen:
  • This release is a synchronization with XenServer release 4.17.7-4. XSAs 517, 518, and 520 patches that were included in XCP-ng previous releases are now part of this XS release.
  • This release also fixes a possible microcode hang on Granite Rapids systems.

Control Plane

• xapi:

  • Fix a metadata corruption (VDI.snapshot_of, see the corresponding troubleshooting page). Note that the old corrupted snapshot_of references still need to be fixed up by the snapshot-fixer.py helper script. This is part of a series of fixes on this long and complex "snapshot_of" metadata inconsistency fixing quest. Whether this will prevent all future occurrences of issues related to this field is yet unknown.
  • Fix issues for PCI passthrough of some devices (AMD and Intel GPUs, Kioxia SSDs) by disabling HVM PIRQ
  • PCI passthrough: HVM PIRQ now disabled by default. Some devices passed through to VMs (AMD and Intel GPUs, Kioxia SSDs) could have problems caused by the "HVM PIRQ" feature (see the troubleshooting section). This update disables it by default on HVM VMs. The new default applies the next time a VM starts or reboots. If you set platform:hvm-pirq on a VM yourself, that value is kept.
  • Improve performance of xapi-nbd (used by XenOrchestra backups)
  • Fix XenOrchestra backups of VDIs on shared SRs failing when a pool has offline hosts
  • Prevent SR issues from blocking XAPI startup
  • Report a clear error during HA when host evacuation is blocked by unprotected VMs

• xcp-ng-xapi-plugins:

  • lsblk.py : Add a new output in lsblk device-id-paths that is a list of paths on the host using stable identifier.
  • service.py: Restrict which services the plugin is allowed to stop/start

Storage

• blktap: Several tapdisk improvements:

  • Qcow2 support introduced multithread and therefore locking. One of the blkif's critical session protected by a lock was larger than necessary. By restricting locking at the blkif level, write operations on Qcow2-format VDIs can see great performance improvement if there is sufficient I/O depth.
  • Fix a potential crash on NBD server handshake connection. This was observed under artificial conditions and should not happen in real scenarios.
  • Storage team continue to modernize the tapdisk codebase to allow more improvements in the future. No functional change expected here but preparatory work on next features.

• sm:

  • Repair plugin method healthCheck of linstor-manager that was broken due to internal refactoring.
  • Repair regression caused by previous release where LINSTOR HA cannot be activated.
  • Reset on boot feature is now usable on ZFSSR driver using on-boot param with persist or reset values.

For XOSTOR users:

• xcp-ng-linstor: Fix rolling pool updates with large pools using XOSTOR

UI

• xo-lite:
  • [Host] Add possibility to reboot a host (PR #10250)
  • [Web-Core/TabItem] Update the component to remove uppercase for better readability (PR #10338)
  • [Host] Add possibility to force reboot a host (PR #10311)
  • [Icons] Update FontAwesome, clean unused libraries (PR #10365)
  • [Host] Add possibility to shut down and start a host (PR #10314)
  • Use MenuItem's accent prop to color menu actions instead of custom CSS classes (PR #10348)
  • [Host] Add possibility to forget a host (PR #10315)
  • [Pool/Network] Add the possibility to delete host internal networks (PR #10332)

Drivers and Firmware

• amd-microcode: Update to 2026-09-23 drop as redistributed by XenServer. Updated CPUs

  • BRH-C1 00b00f21: 2025-10-17, rev 0b002162 -> 2026-08-10, rev 0b00217b
  • BRHD-B0 00b10f10: 2025-10-17, rev 0b101059 -> 2026-08-10, rev 0b101068

• intel-microcode:

  • Update to the 2026-09-25 drop. This is IPU 2026.3 with fixed Meteor Lake microcode.
  • fix of a bugus microcode for Sierra Forest (E-Core) CPUs.
  • microcode update for Granite Rapids to address a security vulnerability for which a mitigation had already been released in previous updates (https://xcp-ng.org/blog/2026/10/13/october-2026-security-updates-2-for-xcp-ng-8-3-lts/).
  • Removed MTL/06-aa-04/c0 due to functional issues observed when loading the MCU in some platforms.
  • Updates for functional issues.
  • Security updates for: INTEL-SA-01379, INTEL-SA-01404, INTEL-SA-01423, INTEL-SA-01428, INTEL-SA-01435, INTEL-SA-01441, INTEL-SA-01442, INTEL-SA-01443, INTEL-SA-01420

Others

• sudo: Update to version 1.9.17
  • 3 security fixes of vulnerabilities in sudo which could allow a privilege escalation in certain condition.
  • 1 security fix of a vulnerability allowing a user with temporary authorization to extend their authorization by 24 hours.

Versions

• amd-microcode: 20260519-1.1.xcpng8.3 -> 20260923-1.1.xcpng8.3
• blktap: 3.55.5-11.3.xcpng8.3 -> 3.55.5-12.2.xcpng8.3
• gpumon: 24.1.0-98.1.xcpng8.3 -> 24.1.0-99.1.xcpng8.3
• intel-microcode: 20260416-2.xcpng8.3 -> 20260925-1.xcpng8.3
• sm: 3.2.12-25.1.xcpng8.3 -> 3.2.12-25.2.xcpng8.3
• sudo: 1.9.15-5.1.xcpng8.3 -> 1.9.17-10.p2.1.xcpng8.3
• xapi: 26.1.19-1.2.xcpng8.3 -> 26.1.21-1.1.xcpng8.3
• xcp-featured: 1.2.1-5.xcpng8.3 -> 1.2.1-6.xcpng8.3
• xcp-ng-xapi-plugins: 1.17.0-1.xcpng8.3 -> 1.18.0-1.xcpng8.3
• xen: 4.17.7-2.5.xcpng8.3 -> 4.17.7-4.1.xcpng8.3
• xo-lite: 0.25.0-1.xcpng8.3 -> 0.26.0-1.xcpng8.3

XOSTOR users: specific update procedure

Some XOSTOR packages are provided in separate repository, and should be installed along xcp-ng regular packages, using the following commands:

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-linstor-testing
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-linstor-testing
reboot

The following XOSTOR-specific package received an update:

• xcp-ng-linstor: 1.2-6.xcpng8.3 -> 1.2-7.xcpng8.3

Test on XCP-ng 8.3

Warning: XOSTOR users should skip this part and follow the instructions of the previous section.

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

What to test

Normal use and anything else you want to test, as usual. We mostly want to make sure nothing regressed. These checks would help us most:

1. Reboot your VMs, starting with Linux VMs that use PCI passthrough (GPU, NVMe, NIC). The new HVM PIRQ default applies to every VM at its next boot. If you set platform:hvm-pirq on a VM yourself, that value is kept. Devices that worked before must still work, with similar performance and CPU usage. If one doesn't, check whether platform:hvm-pirq=true brings it back, and tell us.
2. Run your usual Xen Orchestra backups (incremental with NBD, full) and a restore. Every NBD backup now goes through new code (tapdisk's NBD server, parallel requests), so they must complete, and shouldn't get slower.
3. Watch the disk performance of your busiest VMs, on VHD and QCOW2 SRs. The locking change in tapdisk applies to every VM disk, not only QCOW2.
4. After running the snapshot_fixer.py script if necessary, take, revert to and delete snapshots, including on VMs with several disks, and check that the VMs and their disks are as expected afterwards. The fix changes how xapi handles VDIs during reverts and SR scans.

Test window before official release of the updates

~5 days

We would like to thank users who shared feedback since our last call for testing:
@flakpyro, @acebmxer, @abudef, @bufanda, @jr-m4, @JeffBerntsen, @Andrew