Dirty Frag [CVE Pending]: Mitigation and Kernel Update on CloudLinux
Dirty Frag [CVE Pending] is a Linux kernel local privilege escalation in the xfrm subsystem. The flaw lives in the ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path and is reachable via the XFRM user netlink interface, which auto-loads the relevant modules. A working public proof-of-concept exists; any unprivileged local user can use it to gain root in a single command.
The vulnerability is in the same class as Copy Fail (CVE-2026-31431) but lives in a different subsystem.
Details: public PoC and write-up · Dirty Frag disclosure
Status as of 2026-05-07, 20:30 UTC
Patched kernels and KernelCare livepatches for affected CloudLinux versions are in active build/test. See Update instructions below for current per-stream status. This article will be updated in place as each stream reaches release.
Subscribe to the CloudLinux status page for updates.
Affected CloudLinux versions
| Version | Affected | Will be patched via |
|---|---|---|
| CL7 | Under investigation | Under investigation |
| CL7h | Yes | CloudLinux kernel |
| CL8 | Yes | CloudLinux kernel |
| CL9 | Yes | AlmaLinux kernel |
| CL10 | Yes | AlmaLinux kernel |
A KernelCare livepatch will also be available as an alternative on all affected versions. See Stream 3 below for current status.
Apply this mitigation now
Until a patched kernel or KernelCare livepatch is installed, blacklist the esp4, esp6, and rxrpc modules so they cannot be loaded, and unload them if already present:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
To revert after a patched kernel is installed:
sudo rm /etc/modprobe.d/dirtyfrag.conf
Compatibility: esp4 / esp6 are the kernel-side ESP transforms used by IPsec. Disabling them breaks IPsec tunnels that rely on the kernel data path on the affected machine. Do not apply this mitigation on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels. rxrpc is the AF_RXRPC transport used almost exclusively by AFS clients and is not present on typical web-hosting servers.
Restore on-disk binaries after mitigation
The exploit can modify legitimate system binaries in page-cache as part of gaining root, so applying the mitigation alone is not enough on systems that may have been targeted before it was in place. After mitigating, drop page-cache:
sudo echo 3 > /proc/sys/vm/drop_caches
Additional protection for Imunify360 users
We identified IOCs associated with a Bash script that prepares the payload, compiles the exploit, and executes it to achieve privilege escalation. The related script has already been blacklisted on Imunify360.
This is an additional layer of defense. It does not replace the kernel update, but customers running Imunify360 are covered with further protection in the meantime.
Update instructions
There are three release streams. Use the one that applies to your CloudLinux version. As patches land, this article will be updated in place. Check the timestamps on the callouts in each stream below.
Stream 1 — CloudLinux kernel (CL7h, CL8)
Status: May 7, 20:30 UTC
Patched kernels are in build/test on top of the AlmaLinux 8 fix. Target package versions and channel availability are coming soon.
Both CL7h and CL8 will be CloudLinux rebuilds of the upstream fix.
Stream 2 — AlmaLinux kernel (CL9, CL10)
Status: May 7, 20:30 UTC
AlmaLinux is preparing the patched kernel. Target package versions and repository availability will be added here as soon as upstream announces.
CloudLinux 9 and CloudLinux 10 use the AlmaLinux kernel directly. The patched kernel is expected to appear first in the AlmaLinux testing repository, with promotion to production repositories shortly after.
Stream 3 — KernelCare livepatch (all affected versions)
Status: May 7, 20:30 UTC
KernelCare engineering is preparing livepatches. Per-distro release status will be appended here as patches roll out.
The KernelCare livepatch for this vulnerability is being prepared. Once published, KernelCare-subscribed systems will receive the fix automatically through the usual livepatch flow:
kcarectl --update
kcarectl --info | grep [CVE-ID]
The CVE should appear as patched in the kcarectl --info output.
Not using KernelCare yet? You can get started in just a few minutes. Find more information here.
How to verify you are patched
After update + reboot:
uname -r
Compare to the target version for your CloudLinux stream above.
For KernelCare:
kcarectl --info | grep [CVE-ID]




