Updates published: https://xcp-ng.org/blog/2025/10/23/october-2025-security-and-maintenance-update-for-xcp-ng-8-3-lts/

Thank you for the tests!

New update candidates for you to test! (adding to the previous batch again)

New updates join the previous batch of update candidates. They're the last ones.

A new XSA (Xen Security Advisory) was published on the 21th of October, and updates to Xen address the disclosed vulnerabilities. We also reverted a change in XAPI that we deemed risky.

Additionally, we also publish an updated Intel-Ice alternate driver.

• xen:

  • XSA-475 - Potential risks include Denial of Service (DoS) impacting the whole host, information exposure, or escalation of privileges. There are two vulnerabilities related to hypercalls in the Viridian code:
    • CVE-2025-58147: Out-of-bounds write in vpmask_set() from hypercalls using the HV_VP_SET Sparse format.
    • CVE-2025-58148: Out-of-bound read in send_ipi() from hypercalls using any format, that could lead to a wild vCPU pointer.

• xapi:

  • We reverted a change related to how rsyslog configuration is handled. The way XenServer handled the change seemed risky to us, we'll take the time to make it in a safer way.

Optional packages:

• Alternate Driver: Updated to newer version.
  • intel-ice-alt: Update driver sources to v1.17.2

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

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

Versions:

• xapi: 25.27.0-2.2.xcpng8.3
• xen: 4.17.5-20.2.xcpng8.3

Optional packages:

• Alternate drivers:
  • intel-ice-alt: 1.17.2-1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

~2 days.

The kernel-alt is there for debugging purposes and should not be used during normal operation, especially if you want to maintain optimal performance.

Alternative driver versions may be offered instead of driver updates. This is the case for the Intel i40e. The default version is 2.25.11-2, and its alternative (-alt) version is 2.26.8-1. This is simply a more up-to-date version of the driver.

You can therefore try this version (which is independent of the kernel-alt). It installs over the default XCP-ng installation and therefore over the standard kernel:

yum install intel-i40e-alt

Hopefully this more up-to-date version will help you.

XCP-ng 8.2 has just reached its end of life, but the adventure continues with XCP-ng 8.3 (and other versions to come). You can read the communication on this point on our blog: https://xcp-ng.org/blog/2025/09/16/xcp-ng-8-2-lts-reached-its-end-of-life/

To continue benefiting from updates and developments, we invite you, if you haven't already done so, to upgrade your systems to XCP-ng 8.3.

A relevant thread has been around for quite some time if you want to participate in early testing of the updates: https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/

Updates published: https://xcp-ng.org/blog/2025/09/11/september-2025-security-update-for-xcp-ng-8-3-lts/

Thank you for the tests!

Updates published: https://xcp-ng.org/blog/2025/09/11/september-2025-security-update-for-xcp-ng-8-2-lts/

Thank you for the tests!

New security update candidates for you to test!

A new XSA (Xen Security Advisory) was published on the 9th of September, and an update to Xen addresses it.

---

• xen-*:
  • Fix XSA-472 — Potential risks include Denial of Service (DoS) impacting the whole host, information exposure, or escalation of privileges. There are several vulnerabilities associated with the way guest memory pages are handled and accessed in the Viridian code:
    • NULL pointer dereference during reference TSC area update — This issue occurs when the system tries to update the reference TSC area but encounters a NULL pointer. (CVE-2025-27466)
    • NULL pointer dereference when delivering synthetic timer messages — This happens if the code assumes the SIM page is already mapped when a synthetic timer message must be delivered. (CVE-2025-58142)
    • Race condition in reference TSC page mapping — A guest system can trigger Xen to release a memory page while it is still referenced in the guest’s physical-to-machine (p2m) page tables. (CVE-2025-58143)

Test on XCP-ng 8.2

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

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

Versions:

• xen: 4.13.5-9.49.4.xcpng8.2

What to test

• Normal use and anything else you want to test.

Test window before official release of the updates

~2 days.

Remarks

Another XSA (474) was released the same day regarding XAPI. Since the attack vector differs and is not easily exploitable in 8.2, we have not released a patch for it, unlike in 8.3.

As a reminder, XCP-ng 8.2 LTS will no longer be supported as of September 16, 2025.

We therefore strongly encourage you to migrate your pools to XCP-ng 8.3 LTS to continue benefiting from the latest security fixes and improvements.

New security update candidates for you to test!

News XSAs (Xen Security Advisory) were published on the 9th of September, and updates to Xen & XAPI address them.

• xapi:

  • Fix XSA-474 — A Denial of Service can be caused by buggy or malicious inputs to XAPI (CVE-2025-58146). There are several vulnerabilities identified in XAPI:
    • Input sanitisation mismatch in notifications — While updates to the XAPI database correctly sanitise input strings, the system generates notifications using the unsanitised version. This flaw causes the database’s event thread to crash, halting further processing.
    • Inconsistent UTF-8 handling — XAPI’s UTF-8 encoder follows version 3.0 of the Unicode specification, whereas some of the libraries it relies on enforce the stricter version 3.1 standard. As a result, certain strings may be accepted as valid UTF-8 by XAPI but rejected by other components. If such strings are entered into the database, the database can subsequently fail to load.
    • Lack of sanitisation in Map/Set updates — When updating Map/Set objects in the XAPI database, no sanitisation is applied to the inputs, which introduces additional risks.

• xen-*:

  • Fix XSA-472 — Potential risks include Denial of Service (DoS) impacting the whole host, information exposure, or escalation of privileges. There are several vulnerabilities associated with the way guest memory pages are handled and accessed in the Viridian code:
    • NULL pointer dereference during reference TSC area update — This issue occurs when the system tries to update the reference TSC area but encounters a NULL pointer. (CVE-2025-27466)
    • NULL pointer dereference when delivering synthetic timer messages — This happens if the code assumes the SIM page is already mapped when a synthetic timer message must be delivered. (CVE-2025-58142)
    • Race condition in reference TSC page mapping — A guest system can trigger Xen to release a memory page while it is still referenced in the guest’s physical-to-machine (p2m) page tables. (CVE-2025-58143)

Test on XCP-ng 8.3

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

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

Versions:

• xapi: 25.6.0-1.12.xcpng8.3
• xen: 4.17.5-15.3.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

~2 days.

Updates published: https://xcp-ng.org/blog/2025/09/01/september-2025-maintenance-update-for-xcp-ng-8-3/

Thank you for the tests!

New update candidate for you to test!

A new non-urgent update is ready for user testing before a future collective release. Below are the details.

---

Maintenance updates

• broadcom-bnxt-en: Update driver to version 1.10.3_232.0.155.5

Test on XCP-ng 8.3

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

A reboot is preferable to load the new version of the driver.

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

Versions:

• broadcom-bnxt-en: 1.10.3_232.0.155.5-1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

None defined, but early feedback is always better than late feedback, which is in turn better than no feedback

New update candidate for you to test!

A new non-urgent update is ready for user testing before a future collective release. Below are the details.

A bug was found in the Emergency Network Reset due to desynchronisation between xsconsole and XAPI. This issue prevented the Emergency Network Reset from working at all. This update includes the fixes from the upstream xsconsole project to fix it.

---

Maintenance updates

• xsconsole
  • Backport sync of network reset trigger file path with XAPI to fix emergency network reset
  • Backport fix for pool.conf IPv6 to avoid IPv6 truncation

Test on XCP-ng 8.3

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

Reboot is not strictly necessary, but the xsconsole instance running on the first virtual terminal of your host won't be restarted otherwise. If you do not reboot, make sure to start xsconsole from another terminal after the update.

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

Versions:

• xsconsole: 11.0.8-1.2.xcpng8.3

What to test

Normal xsconsole usage, is still useful feedback. However, if possible, the most helpful test would be performing an Emergency Network Reset through xsconsole, making actual configuration changes and verifying that they are correctly applied after reboot.

Test window before official release of the updates

None defined, but early feedback is always better than late feedback, which is in turn better than no feedback

The fix, which was proposed as a test to resolve some of the issues encountered, has been integrated into an official update candidate which will be released to everyone next time we publish updates. For more information on this update, you can consult the following post: https://xcp-ng.org/forum/post/96135

New update candidates for you to test!

A new batch of non-urgent updates is ready for user tests before a future collective release. Below are the details about these.

---

Maintenance updates

• blktap: Fix a bad integer conversion that interrupts valid coalesce calls on large VDIs. This fixes an error that could occur on VHD coalesces, generating logs on the SMAPI side.
• kernel:
  • Fix compatibility issues with Minisforum MS-A2 machines. For more information, you can consult this forum post.
  • Backport fix for CVE-2020-28374, a vulnerability that is unlikely to be exploitable in XCP-ng, fixed as defence-in-depth.
• xapi & xen:
  • Add a new /etc/xenopsd.conf.d directory, in which users can add a .conf file with configuration values for xenopsd.
  • Patch Xen to support a new option allowing to activate the remapping of grant-tables as Writeback. This fixes a performance issue for Linux Guests on AMD processors. Guests need their kernel to support the feature which enables this fix (Linux distributions that have recent enough kernels or apply fixes from the mainline LTS kernels are OK. Older ones are not. Some currently supported LTS distros don't have the patch yet: RHEL 8 and 9 and their derivatives are not ready yet - no effect on older distros such as Ubuntu 20.04. See partial list below). Windows and *BSD guests were not affected by the performance problem this change solves.
  • While we are confident with this change, we decided to make it opt-in at first, so that users be conscious of the change and also know how to revert it if any side effects remain in edge cases. To enable the fix pool-wide, create a file named /etc/xenopsd.conf.d/custom.conf with the following line:

    xen-platform-pci-bar-uc=false
    

    • Then restart the toolstack on the host: xe-toolstack-restart
    • Then add the configuration and restart the toolstack on every other hosts of the pool
    • Then stop and start VMs so that the setting is applied to them at boot.
  • In a future update, this will become the default.
  • This is not the end of the way towards better performance on AMD EPYC servers, but it's significant progress!
• xo-lite:
  • [Host/VM/Dashboard] Fix display error due to inversion of upload and download
  • [Sidebar] Updated sidebar to auto close when the screen is small
  • [SearchBar] Updated query search bar to work in responsive (PR #8761)
  • [Pool,Host/Dashboard] CPU provisioning considers all VMs instead of just running VMs
  • For more details, we invite you to read the blog post about the latest Xen-Orchestra update.

OS support for the AMD performance workaround:

• Debian: 11 (5.10: TODO), 12 (6.1: OK)
• Ubuntu: 20.04 LTS (5.4: EOL), 22.04 LTS (5.15: SOON, HWE 6.8: OK), 24.04 LTS (6.8 & HWE 6.14: OK)
• openSUSE Leap, 15.5 (5.14: EOL) 15.6 (6.4: OK)
• SUSE Enterprise (LTSS) : SLE15 SP3 - LTSS (5.3: Not upstream), SLE15 SP4/5 - LTSS (5.14: Not upstream), SLE15 SP6+ (OK)
• RHEL (+derivates): 8 (4.19: EOL-ish?), 9 (5.14: Not upstream), 10 (6.12: OK)
• Fedora: All supported: OK (37+)
• Alpine Linux: All supported: OK (v3.18+)

• EOL = distro is EOL
• Not upstream = not covered by Linux stable project (i.e probably needs discussions with distro)
• SOON: Distro needs to update its kernel

Test on XCP-ng 8.3

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

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

Versions:

• blktap: 3.55.5-2.3.xcpng8.3
• kernel: 4.19.19-8.0.38.4.xcpng8.3
• xapi: 25.6.0-1.11.xcpng8.3
• xen: 4.17.5-15.2.xcpng8.3
• xo-lite: 0.13.1-1.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

None defined, but early feedback is always better than late feedback, which is in turn better than no feedback

Hello,

We've added a card to our backlog to investigate this topic.

Updates published: https://xcp-ng.org/blog/2025/07/29/july-2025-security-update-2-for-xcp-ng-8-2-lts/

Thank you for the tests!

New security update candidate

A new XSA (Xen Security Advisory) was published on the 8th of July, and an update to Xen addresses it.

---

Security updates

• linux-firmware: Update to 20250626-1 as redistributed by XenServer.
• xen-*:
  • Fix XSA-471 - New speculative side-channel attacks have been discovered, affecting systems running all versions of Xen and AMD Fam19h CPUs (Zen3/4 microarchitectures). An attacker could infer data from other contexts. There are no current mitigations, but AMD is producing microcode to address the issue, and patches for Xen are available. These attacks, named Transitive Scheduler Attacks (TSA) by AMD, include CVE-2024-36350 (TSA-SQ) and CVE-2024-36357 (TSA-L1).

Test on XCP-ng 8.2

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

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

Versions:

• linux-firmware: 20190314-11.3.xcpng8.2
• xen: 4.13.5-9.49.3.xcpng8.2

What to test

On Intel platform:

• Normal use and anything else you want to test.

On AMD platform zen3 or zen4:

• Normal use of course
• On a Linux guest, with cpuid installed, run the command following command:

lscpu | grep -q AMD && lscpu | grep -qi "cpu family.* 25$" && [ $(($(cpuid -1 -r -l 0x80000021 | grep eax | sed -r 's/.*eax=([^ ]+) .*/\1/') & 0x20)) -eq 32 ] && echo OK

This should print OK if your system is protected against XSA-471.

Test window before official release of the updates

~3 days.

@manilx We recently upgraded our Koji build system. This may have caused disruptions in this recent update release yesterday, where an XML file was generated multiple times. This has now been fixed and should not happen again. This may explain the issue encountered this time, particularly with the notification of updates via XO.

Note that normally yum metadata expires after a few hours and so it should normally return to normal on its own.

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

yum clean all

I can't explain it. I can't say what's going on on your system, especially with so little information.

Personally, I run the following commands all the time:

yum clean metadata ; yum update

I very rarely need to use yum clean all, and I don't remember having to do an additional rm. And yet, I run the above commands a lot during testing campaigns.

@flakpyro Yes, it always takes a little time for the mirrors to synchronize.

I'm getting correct feedback from the main repository (https://updates.xcp-ng.org/) with the correct updates available.

Updates published: https://xcp-ng.org/blog/2025/07/15/july-2025-security-update-2-for-xcp-ng-8-3-lts/

Thank you for the tests!