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

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