Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    4k Posts
    rzrR
    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. 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 ED25519 keys. Others libtasn1: Update to 4.21.0 (hardening) fuse: Rebuild slang: Rebuild systemtap: Rebuild Optional packages libreswan: Rebuild netdata: Rebuild Versions: blktap: 3.55.5-6.7.xcpng8.3 -> 3.55.5-9.1.xcpng8.3 dmidecode: 1:3.0-5.el7 -> 1:3.6-3.xcpng8.3 edk2: 20220801-1.7.10.1.xcpng8.3 -> 20220801-1.7.11.1.xcpng8.3 fuse: 2.9.2-10.xcpng8.3 -> 2.9.2-10.1.xcpng8.3 ipxe: 20121005-1.0.7.xcpng8.3 -> 20121005-1.0.8.xcpng8.3 kernel: 4.19.19-8.0.46.3.xcpng8.3 -> 4.19.19-8.0.46.5.xcpng8.3 libreswam: 4.12-2.3.1.xcpng8.3 -> 4.12-2.3.2.xcpng8.3 libtasn1: 4.10-1.el7 -> 4.21.0-1.xcpng8.3 openssh: 9.8p1-1.2.3.xcpng8.3 -> 9.8p1-1.2.4.xcpng8.3 netdata: 1.47.5-4.2.xcpng8.3 -> 1.47.5-4.3.xcpng8.3 qemu: 2:4.2.1-5.2.17.1.xcpng8.3 -> 2:4.2.1-5.2.18.1.xcpng8.3 slang: 2.3.2-11.xcpng8.3 -> 2.3.2-11.1.xcpng8.3 systemtap: 4.0-5.2.xcpng8.3 -> 4.0-5.3.xcpng8.3 varstored: 1.3.1-2.1.xcpng8.3 -> 1.3.2-2.1.xcpng8.3 xapi: 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 reboot The 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.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    Honestly, the confusion makes total sense; GitHub does a great job of hiding this stuff. Here's what's going on: those markdown files only exist right now as a proposed change sitting on a branch. That's the whole reason you can only get to them through the pull link, and nowhere else. They become a real, permanent part of the repo the moment you merge them in. And since it's your repo, that merge is yours to do, no special GitHub-fu required. Open the PR page (https://github.com/tobiaskreidl/Citrix-Tobias-Kreidl-Collection/pull/1), scroll down a bit, and click the green Merge pull request button. That's the "commit" step you were asking about. There's one wrinkle worth knowing about, and it's the real reason none of this shows up on your main repo page. Your repository has a couple of branches. Your existing PDFs and the Word doc live on a branch called XenServer-Articles, so I pointed my PR at that same branch to drop the markdown right next to them. But the page GitHub shows when someone visits your repo is a different branch called main, which at the moment only holds a README. So even after you merge, the articles will sit on XenServer-Articles, not on that front page. That's actually been true of your PDFs all along; it's nothing my PR changed. If you'd like the articles to show up on the landing page too, there are two easy ways, and I'm happy to do either one for you. We can change the repo's default branch to XenServer-Articles in Settings > Branches, so that one becomes the front page. Or I open a second small PR copying everything over to main. Just tell me which you'd rather have. So the short version: merge the PR to make the markdown real, then we can decide whether you also want the front page pointing at the articles. No rush at all on that second part. gounthar opened this pull request in tobiaskreidl/Citrix-Tobias-Kreidl-Collection open Add Markdown versions of the three articles (render inline on GitHub) #1

  • All Xen Orchestra related questions/reports

    3k Topics
    28k Posts
    MathieuRAM
    Hi @r0123456789, GET /rest/v0/hosts/:id/stats is available in the REST API

  • Our hyperconverged storage solution

    47 Topics
    746 Posts
    poddingueP
    This is a tricky one, and I'm a bit out of my depth on the XOSTOR internals, but the pattern you describe (XO losing the pool for 30 to 60 seconds while SSH and ping to the hosts stay perfectly fine) reads more like XAPI stalling on a storage call during the LINSTOR coordination than a real network drop. One detail caught my eye: you mention XOSTOR is on the 10Gb storage network only. The XOSTOR docs actually recommend the satellites stay on the XAPI management interface and call a dedicated network for them "not recommended" for pool robustness (https://docs.xcp-ng.org/xostor/), which feels counterintuitive with a fast 10Gb link sitting right there, so I may well be misreading your setup. If you're able to grab /var/log/SMlog and /var/log/xensource.log on the master host during one of the disconnect windows, that should show whether XAPI is timing out waiting on a storage operation. Nobody's chimed in yet, and this is pretty XOSTOR-specific, so it might be worth a mention to @Team-Storage; they'll know far more than I do about whether the satellite-network config is what's triggering it.

  • Non-English speakers

    35 Topics
    113 Posts
    olivierlambertO
    Ah excellente nouvelle Je passe le sujet en résolu !