Issue
A vulnerability was recently discovered in the Linux Kernel named "Dirty Frag", which allows for Local Privilege Escalation (LPE) to the root user. "Dirty Frag" (CVE-2026-43284) is a similar exploit to the recent "Copy/Fail" (CVE-2026-31431) vulnerability disclosed recently and is a continuation of a previous vulnerability named "Dirty Pipe" (CVE-2022-0847). This vulnerability is found in the Linux Kernel itself and thus is present in multiple Linux distributions.
Environment
- CloudLinux
- Kernelcare
Solution
Patched kernels and KernelCare livepatches are both available. The update path is under "Getting onto a fixed kernel" at the end of this section. The manual workaround below is kept for hosts that cannot reboot yet.
Immediate Mitigation (Manual Workaround):
If you cannot wait for the patched kernel and your server does not rely on IPsec/VPN tunnels (such as strongSwan or Libreswan), you should block the vulnerable modules immediately:
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"This prevents the kernel from auto-loading the code used in the exploit.
To Revert (After Patching):
sudo rm /etc/modprobe.d/dirtyfrag.confCompatibility: 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 to 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.
Getting onto a fixed kernel
Patched kernels are in the stable channel, so a plain update is enough. Update the kernel packages together with kmod-lve, otherwise LVE will not load on the new kernel.
yum update kernel kernel-core kernel-modules kernel-headers kernel-tools kernel-tools-libs kmod-lve
Reboot, then confirm with uname -r.
While the fix was still rolling out, the working advice was different. It pulled the kernel from a bypass rollout slot and reached cloudlinux-release through the testing repository, both as one-off --enablerepo flags. Neither belongs in a repository file afterwards. If cloudlinux-updates-testing was switched on by editing /etc/yum.repos.d/cloudlinux.repo rather than by the flag, check it and set it back.
grep -A4 '^\[cloudlinux-updates-testing\]' /etc/yum.repos.d/cloudlinux.repo
The shipped value is enabled=0. If the server shows enabled=1, turn it off.
dnf config-manager --set-disabled cloudlinux-updates-testing
Leaving it on has a second effect that is easy to miss. CloudLinux serves the stable channel per minor release, so a server whose cloudlinux-release is behind sees a frozen stable content set, while the testing URL is not tied to a release and keeps returning current packages. The result looks like a broken stable repository. New kernels appear only under testing, and the fix for whatever comes next looks unavailable. Keep cloudlinux-release current and the problem does not arise.
yum update cloudlinux-releaseFor more details, please refer to:
Cause
Dirty Frag (CVE-2026-43284) 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.
Comments
0 comments
Please sign in to leave a comment.