XOA vulnerabilty to "copy fail" and "dirty frag" bug

rvreugde

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.html

Are 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.

bleader

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:

Rod G

@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?

semarie

please note that blacklisting ESP modules will break IPsec, and encrypted private tunnels rely on it.

Rod G

@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.

olivierlambert

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/

Rod G

I want to correct something I said in my earlier post, now that I've done a deeper analysis of the exploit chain.

I described the RxRPC component as being responsible for heap memory grooming, and suggested that without it a sophisticated attacker would need to find an alternative grooming technique. That framing was inaccurate, and I don't want it to create false reassurance in the community.

Here is what's actually going on:

RxRPC (CVE-2026-43500) was not added to the exploit chain to groom memory. It was added specifically to bypass Ubuntu's AppArmor policy, which blocks unprivileged user namespace creation by default. On Ubuntu, the ESP4 path requires unshare() to create a user namespace, and AppArmor prevents that — so the RxRPC path provides an alternative write primitive that doesn't need a namespace at all.

XCP-ng dom0 has no AppArmor. It is built on a CentOS 7 base where unprivileged user namespace creation is permitted by default. This means the ESP4 path (CVE-2026-43284) works directly, without any namespace restriction to bypass and without needing RxRPC at all.

The practical consequence: every supported XCP-ng installation (8.1, 8.2, 8.3) is fully exploitable via CVE-2026-43284 alone. The absence of rxrpc.ko does not provide protection on this platform. The older OS base actually makes the ESP4 path more straightforward to reach, not less.

I'm holding off publishing my diagnostic tool to give the VATES team time to finalise their VSA and patches for XCP-ng. In the meantime, the interim mitigation stands as I described — with @semarie's important caveat: blacklisting esp4/esp6 will break IPsec and the SDN controller's encrypted private tunnels. Check your environment before applying it.

And as I noted in my follow-up: this remains an LPE. If you have no unprivileged service accounts on dom0 (no Terraform, no monitoring agents, no central logging), your exposure is already limited. Audit what has shell access to dom0 and remove anything that doesn't strictly need it.