XCP-ng 8.3 updates announcements and testing
-
@probain Hello,
It's likely linked to the
List index out of rangebug.
That bug was linked to the SR scan failing to introduceCBT_metatadataVDI in the XAPI database, could you try to launch axe sr-scan uuid=<SR UUID>and try again to disable CBT?
If it does not work, could you share the/var/log/SMlogof around the time you are trying to disable CBT? -
acebmxer said:
acebmxer said:
I have issue with rolling pool update with 1 of my 3 pools at work. It was the last pool to be updated. Host 1 updated no issues. vms stopped migrated off host 2 to complete updates.
Support ticket opened -
Ticket#7758427. Found 1 vm with cpu stuck at 100% and unresponsive. Force rebooted vm and proceed updates on host2.Well I think i found the source of my problems. After having continues other odd issues with this remote pool. I decided i was going to reboot everything. That's when every vm started to fail. Logged into Synology rs1221+ and it was just very sluggish and not responsive. No new error alerts or anything to explain the odd behavior. Rebooted it and even after boot still odd behavior until finally disk error. Then the system started to respond.
Luckily I have a spare drive onsite but cant gain access until Monday possibly Tuesday. Fingers crossed. Lucky for backups. Looks like the important vms had a successful backup as of yesterday so thats good.
Still having issues with this remote pool. Synology is still rebuilding the storage pool, but the time seems unreal to complete 80+ days. It keeps dropping and increasing... Yet I tried to migrate vm from NFS SR to local storage and vm having issues boot. Try to determining but i think i have multiple issue just not sure which ones.
-
@probain Hello,
It's likely linked to the
List index out of rangebug.
That bug was linked to the SR scan failing to introduceCBT_metatadataVDI in the XAPI database, could you try to launch axe sr-scan uuid=<SR UUID>and try again to disable CBT?
If it does not work, could you share the/var/log/SMlogof around the time you are trying to disable CBT?I've sent you a DM for sharing the logs.. Unfortunately I "solved" the issue by deleting all snapshots related to each VM. Including CBT ones. That did make it so I could toggle CBT on the VDIs again.
But I've collected the logs for you.
This also seems like a good time to raise my suggestion to have somewhere at vates where we could upload details in a similar way to how TrueNAS does it. Suggested here: https://feedback.vates.tech/posts/69/suggesting-to-add-a-debug-file-option
-
New security and maintenance update candidates for XCP-ng 8.3 LTS (kernel)
This release batch contains security fixes on the Linux kernel in dom0, version updates, some bug fixes and a few improvements.
What changed
Virtualization & System
-
kernel: Update to 4.19.19-8.0.46.5- Fixes multiple vulnerabilities:
- CVE-2026-46300: A logic error in the network stack could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files that were not supposed to be writable. The modifications are not persistent to a reboot (i.e. no disk corruption). This vulnerability is used by the public exploit
Fragnesia. - CVE-2026-46333: Incorrect tracking of users privilege level when a task is exiting in the ptrace sub-system could allow an unprivileged local user to escalate its privileges to root by writing to file descriptors they are not supposed to have access to. The changes made to potentially root-owned files are persisted across reboots. This vulnerability is used by the public exploits ssh-keysign-pwn as well as
ptrace_may_dream. - CVE-2026-43494: A double-free of pinned pages in the RDS kernel module in the transmit error path could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files, allowing them to for example overwrite a SUID binary in page cache with a shellcode. Changes are not persistent across reboots. This vulnerability is used by the public exploit
pintheft.
- CVE-2026-46300: A logic error in the network stack could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files that were not supposed to be writable. The modifications are not persistent to a reboot (i.e. no disk corruption). This vulnerability is used by the public exploit
- Fixes multiple vulnerabilities:
-
qemu: Fix a potential issue in guest memory mapping lookup. -
edk2:- Fix issues while booting from physical CD/DVD drive.
- Bump UEFI guest vCPU limit to 128 vCPU (was 96 vCPUs)
-
dmidecode: Update to 3.6-3- Version able to read type 42 tables (redfish)
-
varstored: Update to 1.3.2-2.1- Sync with upstream.
-
ipxe: PXE boot support of BIOS VMs on a VLAN with 802.1Q priority tags
Control plane
xapi: Enable USB passthrough of smartcards
Storage
blktap: No functional change. Only sync with upstream.
Network
openssh: Drop support of insecure clients- Old OpenSSH clients (version less than 7.2) can no longer connect with
ssh-rsa(due to SHA-1 being no longer accepted by the server). - The solution is either to update OpenSSH-clients (to a version >= 7.2), or to generate and use
ED25519keys.
- Old OpenSSH clients (version less than 7.2) can no longer connect with
Others
libtasn1: Update to 4.21.0 (hardening)fuse: Rebuildslang: Rebuildsystemtap: Rebuild
Optional packages
libreswan: Rebuildnetdata: Rebuild
Versions:
blktap: 3.55.5-6.7.xcpng8.3 -> 3.55.5-9.1.xcpng8.3dmidecode: 1:3.0-5.el7 -> 1:3.6-3.xcpng8.3edk2: 20220801-1.7.10.1.xcpng8.3 -> 20220801-1.7.11.1.xcpng8.3fuse: 2.9.2-10.xcpng8.3 -> 2.9.2-10.1.xcpng8.3ipxe: 20121005-1.0.7.xcpng8.3 -> 20121005-1.0.8.xcpng8.3kernel: 4.19.19-8.0.46.3.xcpng8.3 -> 4.19.19-8.0.46.5.xcpng8.3libreswam: 4.12-2.3.1.xcpng8.3 -> 4.12-2.3.2.xcpng8.3libtasn1: 4.10-1.el7 -> 4.21.0-1.xcpng8.3openssh: 9.8p1-1.2.3.xcpng8.3 -> 9.8p1-1.2.4.xcpng8.3netdata: 1.47.5-4.2.xcpng8.3 -> 1.47.5-4.3.xcpng8.3qemu: 2:4.2.1-5.2.17.1.xcpng8.3 -> 2:4.2.1-5.2.18.1.xcpng8.3slang: 2.3.2-11.xcpng8.3 -> 2.3.2-11.1.xcpng8.3systemtap: 4.0-5.2.xcpng8.3 -> 4.0-5.3.xcpng8.3varstored: 1.3.1-2.1.xcpng8.3 -> 1.3.2-2.1.xcpng8.3xapi: 26.1.4-3.1.xcpng8.3 -> 26.1.4-3.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 rebootThe usual update rules apply: pool coordinator first, etc.
What to test
As usual, normal use and anything else you want to test.
Test window before official release of the updates
~1 day
We would like to thank users who reported feedback since our last call for testing:
@Andrew, @acebmxer, @flakpyro, @greg_e, @jeffberntsen, @marcoi, @ovicz, @ph7, @probain.
-
-
@rzr
nslookupis broken, but it was before this update too.nslookup vates.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: vates.com Address: 104.21.52.238 Name: vates.com Address: 172.67.205.118 openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace #0 0x7fb705ab80e7 in ?? #1 0x7fb705ab803a in ?? #2 0x7fb7066c5780 in ?? #3 0x7fb704ed0df6 in ?? #4 0x7fb704f17464 in ?? #5 0x7fb704f17732 in ?? #6 0x7fb704f16b8d in ?? #7 0x7fb703681bd9 in ?? #8 0x7fb703681c27 in ?? #9 0x7fb70366a44c in ?? #10 0x405818 in ?? Aborted (core dumped) -
Updated both hosts at home with no issues. Will continue to test.
Dependency Installed: libtasn1-tools.x86_64 0:4.21.0-1.xcpng8.3 Updated: blktap.x86_64 0:3.55.5-9.1.xcpng8.3 dmidecode.x86_64 1:3.6-3.xcpng8.3 edk2.x86_64 0:20220801-1.7.11.1.xcpng8.3 forkexecd.x86_64 0:26.1.4-3.2.xcpng8.3 fuse-libs.x86_64 0:2.9.2-10.1.xcpng8.3 ipxe.noarch 0:20121005-1.0.8.xcpng8.3 kernel.x86_64 0:4.19.19-8.0.46.5.xcpng8.3 libtasn1.x86_64 0:4.21.0-1.xcpng8.3 libtasn1-devel.x86_64 0:4.21.0-1.xcpng8.3 message-switch.x86_64 0:26.1.4-3.2.xcpng8.3 openssh.x86_64 0:9.8p1-1.2.4.xcpng8.3 openssh-clients.x86_64 0:9.8p1-1.2.4.xcpng8.3 openssh-server.x86_64 0:9.8p1-1.2.4.xcpng8.3 qcow-stream-tool.x86_64 0:26.1.4-3.2.xcpng8.3 qemu.x86_64 2:4.2.1-5.2.18.1.xcpng8.3 rrdd-plugins.x86_64 0:26.1.4-3.2.xcpng8.3 slang.x86_64 0:2.3.2-11.1.xcpng8.3 sm-cli.x86_64 0:26.1.4-3.2.xcpng8.3 squeezed.x86_64 0:26.1.4-3.2.xcpng8.3 systemtap-runtime.x86_64 0:4.0-5.3.xcpng8.3 varstored.x86_64 0:1.3.2-2.1.xcpng8.3 varstored-guard.x86_64 0:26.1.4-3.2.xcpng8.3 varstored-tools.x86_64 0:1.3.2-2.1.xcpng8.3 vhd-tool.x86_64 0:26.1.4-3.2.xcpng8.3 wsproxy.x86_64 0:26.1.4-3.2.xcpng8.3 xapi-core.x86_64 0:26.1.4-3.2.xcpng8.3 xapi-nbd.x86_64 0:26.1.4-3.2.xcpng8.3 xapi-rrd2csv.x86_64 0:26.1.4-3.2.xcpng8.3 xapi-storage-script.x86_64 0:26.1.4-3.2.xcpng8.3 xapi-tests.x86_64 0:26.1.4-3.2.xcpng8.3 xapi-xe.x86_64 0:26.1.4-3.2.xcpng8.3 xcp-networkd.x86_64 0:26.1.4-3.2.xcpng8.3 xcp-rrdd.x86_64 0:26.1.4-3.2.xcpng8.3 xenopsd.x86_64 0:26.1.4-3.2.xcpng8.3 xenopsd-cli.x86_64 0:26.1.4-3.2.xcpng8.3 xenopsd-xc.x86_64 0:26.1.4-3.2.xcpng8.3 -
Installed on my test systems and all seems to be working well so far.
-
Thank you for this report, I fear this issue appeared when we rebuilt bind with openssl-3
nslookup vates.com 8.8.8.8
I confirm this issue, note that bind-utils is not installed by default, let me investigate.
-
[09:43 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8 -bash: nslookup: command not found[10:21 xcp-ng-haznrrtw ~]# yum install bind-utils -y Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Excluding mirror: updates.xcp-ng.org * xcp-ng-base: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-updates: mirrors.xcp-ng.org Resolving Dependencies --> Running transaction check ---> Package bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed --> Processing Dependency: bind-libs = 32:9.9.4-63.1.xcpng8.3 for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libbind9.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libdns.so.100()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisc.so.95()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisccc.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisccfg.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: liblwres.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Running transaction check ---> Package bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================================================= Package Arch Version Repository Size ========================================================================================================================================= Installing: bind-utils x86_64 32:9.9.4-63.1.xcpng8.3 xcp-ng-updates 126 k Installing for dependencies: bind-libs x86_64 32:9.9.4-63.1.xcpng8.3 xcp-ng-updates 948 k Transaction Summary ========================================================================================================================================= Install 1 Package (+1 Dependent package) Total download size: 1.0 M Installed size: 3.0 M Downloading packages: (1/2): bind-libs-9.9.4-63.1.xcpng8.3.x86_64.rpm | 948 kB 00:00:00 (2/2): bind-utils-9.9.4-63.1.xcpng8.3.x86_64.rpm | 126 kB 00:00:01 ----------------------------------------------------------------------------------------------------------------------------------------- Total 855 kB/s | 1.0 MB 00:00:01 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64 1/2 Installing : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 2/2 Verifying : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64 1/2 Verifying : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 2/2 Installed: bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3 Dependency Installed: bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3 Complete! [10:22 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: vates.com Address: 172.67.205.118 Name: vates.com Address: 104.21.52.238 openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace #0 0x7f419d8790e7 in ?? #1 0x7f419d87903a in ?? #2 0x7f419e486780 in ?? #3 0x7f419cc91df6 in ?? #4 0x7f419ccd8464 in ?? #5 0x7f419ccd8732 in ?? #6 0x7f419ccd7b8d in ?? #7 0x7f419b442bd9 in ?? #8 0x7f419b442c27 in ?? #9 0x7f419b42b44c in ?? #10 0x405818 in ?? Aborted (core dumpedEdit -No further issues to report at this time.
-
Installed on my usual batch of test hosts, no issues so far.
-
Hi,
I installed the update candidates within my test environment.
Updates installed fine, after reboot all looks good so far.
No apparent issues can be seen.
-
Maybe this schould be under XO/Backup
Anyhow.ph7 said:
Ran the 2 updates released today and...
Back to only showing one VM inBackup/Restoreas it did a month or 2 ago.
Ran the replication job and all VMs showed up inBackup/Restoreagain. (XO5)It occurred again today, only showing 1 VM in restore
XOdaefc
Host updated 2 weeks ago.
After 1 scheduled CR job ran all VMs showed up again -
-
In the back of my head I knew there was a thread and I found it
https://xcp-ng.org/forum/topic/12040/restore-only-showing-1-vm/21?_=1780396449511 -
@rzr
It seems to be working
edit: the update that is. -
@rzr Update installed and running on pools. Normal operations seem good. Had some issues with rolling pool reboot, but that happens a lot (unrelated to updates). An updated
bind-utilswould be nice, and any other SSL affected packages. -
We pushed the tested updates to the xcp-ng-updates repository, check blog post for summary and related advisories:
https://xcp-ng.org/blog/2026/06/02/june-2026-updates-1-for-xcp-ng-8-3-lts/Thank you again for feedback we will try to address reported issues on next batch (to come soon).
Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).
-
@Andrew We'll publish a fix for
bind-utils, indeed, even if it's not part of the officially supported additional packages for XCP-ng, as it can be useful and we don't have strong reasons not to fix it.Regarding other packages affected by the openssl update, @rzr handled many of them as part of the OpenSSL update back then already, so now we'll mostly rely on reports such as yours in case we missed something which is actually used by the user community.
-
Thank you again for feedback we will try to address reported issues on next batch (to come soon).
Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).
Not knowing myself what it meant, I asked Philippe: it's about the nslookup issue. And potentially the issue reported by @ph7 but it's not clear to me yet if there was a problem with XCP-ng or Xen Orchestra.
Anyway, basically this means that there's no known issue caused by this batch of updates, and that we'll keep addressing any relevant issue in the next updates if necessary, as usual.
-
Applied patches at work. 3 pools updated with zero issues.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login