XOA vulnerabilty to "copy fail" and "dirty frag" bug
-
There is currently a lot of discussion about the "Copy Fail" vulnerability and the "Dirty Frag" vulnerability.
Copy Fail: https://thehackernews.com/2026/05/cisa-adds-actively-exploited-linux-root.html
Dirty Frag: https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.htmlAre the XOA appliance (which is based on Debian 12) and XCP-ng vulnerable to these issues?
Should we take any additional mitigation measures?
From what I understand, most Linux distributions already provide a kernel patch for the Copy Fail vulnerability. However, at the time of writing, patches for Dirty Frag do not yet seem to be widely available.
-
Copy Fail is documented in VSA-2026-013, we don't have one for Dirty Frag yet as we're still investigating XCP-ng side regarding it.
For XOA, unattended updates should have installed the patched debian kernel, you just need to reboot it.
Debian security tracker states they are both fixed:
-
@rvreugde As @bleader mentioned, VATES has documented the CopyFail security issue and released a patch. I've put together a lightweight Python script here to help you quickly check if your XCP-ng 8.3 host is vulnerable. If it is, you just need to run yum update and reboot the host (make sure to migrate or shut down your VMs first).
The Dirty Frag vulnerability is a bit more complex. The proof-of-concept (PoC) C code created by Hyunwoo Kim relies on a combination of factors: first, it uses heap memory grooming (manipulating the Linux kernel's protected memory), and then it leverages the esp4/esp6 modules to exploit that memory. This allows an unprivileged OS account to gain root privileges.
Fortunately, XCP-ng does not distribute the RxRPC code that Kim's specific PoC needs to groom the memory. However, the esp4 and esp6 modules are distributed with XCP-ng 8.3 as kernel modules that load on demand. Because of this, a sophisticated attacker could theoretically find an alternative way to groom the kernel memory, force the ESP modules to load, and achieve the same local privilege escalation.
As a potential mitigation, you could blacklist the esp4 and esp6 kernel modules, though I haven't yet investigated what side effects that might cause in an XCP-ng environment.
Hope this helps clarify things!
@bleader Do you know if VATES is now shipping those fixes in the XCP-ng Dom0 Repos?
-
please note that blacklisting ESP modules will break IPsec, and encrypted private tunnels rely on it.
-
@semarie Thank you for the heads up.
@rvreugde I should add an important caveat. Because this is a Local Privilege Escalation (LPE) vulnerability, it requires local access to execute. If you haven't provisioned any unprivileged accounts in Dom0, your exposure is minimal, as an attacker would already need an existing foothold in the host OS to leverage these exploits.
As a side note, I just checked the active XCP-ng repositories for Dom0, and I don't see any official updates or patches pushed out for either vulnerability just yet.
-
Copy fail is already fixed: https://xcp-ng.org/blog/2026/05/05/april-2026-security-and-maintenance-updates-for-xcp-ng-8-3-lts-2/
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