Situation
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" 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.
Impact
All servers running a kernel version after 2017 (starting around Linux version 4.14) are vulnerable to this issue. It is possible for a local user to obtain root level access to a Linux server by modifying the page cache the kernel reads when it loads a binary.
CloudLinux: https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
AlmaLinux: https://almalinux.org/blog/2026-05-07-dirty-frag/
Ubuntu: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
This currently impacts the following Operating Systems:
- CloudLinux 7 Hybrid
- AlmaLinux/Rocky Linux 8
- CloudLinux 8
- AlmaLinux/Rocky Linux 9
- CloudLinux 9
- AlmaLinux 10
- CloudLinux 10
- Ubuntu 20.04
- Ubuntu 22.04
- Ubuntu 24.04
Call to Action
If KernelCare is installed, the running kernel can be patched without a reboot.
el8 family (CL7h, CL8, AlmaLinux 8) — patches available in the testing feed now:
CONFIG_TEXT: kcarectl --update --prefix test
Verify coverage:
CONFIG_TEXT: kcarectl --patch-info | grep CVE-2026-43284
If CVE-2026-43284 appears in the output, the patch is applied. These patches will be promoted to the main feed later today (2026-05-08). Once available in the main feed, a standard update is sufficient:
CONFIG_TEXT: kcarectl --update
el9 family (CL9, AlmaLinux 9) — livepatch in progress. Check the CloudLinux status page for release timing.
If patching is not available, either of the following indicates that KernelCare does not currently cover CVE-2026-43284 for the running kernel:
kcarectl --update returns: There are no updates for this kernel yet kcarectl --patch-info | grep CVE-2026-43284 produces no output
In this case, proceed to the relevant OS tab and apply the temporary mitigation at the bottom of this article while waiting for a patched kernel.
CL7 is not affected. For all other affected versions, patched kernels are being built. Refer to the CloudLinux advisory for current per-stream status and update timing.
CL7h and CL8 — rebuilds based on the AlmaLinux 8 fix (kernel-4.18.0-553.123.2.el8_10). Once available in the beta channel:
CL8:
CONFIG_TEXT: yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
CL7h:
CONFIG_TEXT: yum --enablerepo=cl7h_beta update 'kernel*'
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
Once promoted to the stable channel, no extra repo flag is needed:
CONFIG_TEXT: yum update 'kernel*'
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
CL9 and CL10 use the AlmaLinux kernel directly — see the AlmaLinux tab.
Until a patched kernel is available, apply the temporary mitigation at the bottom of this article.
Patched kernels are available in the AlmaLinux testing repository. Refer to the AlmaLinux advisory for details.
Patched versions:
AlmaLinux 8: kernel-4.18.0-553.123.2.el8_10 and above AlmaLinux 9 / CL9: kernel-5.14.0-611.54.3.el9_7 and above AlmaLinux 10 / CL10: kernel-6.12.0-124.55.2.el10_1 and above
To install from the testing repository, enable it first:
AlmaLinux 10 / CL10:
CONFIG_TEXT: dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
CONFIG_TEXT: dnf update 'kernel*'
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
CONFIG_TEXT: dnf config-manager --disable almalinux-testing
AlmaLinux 9 / CL9:
CONFIG_TEXT: dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm
CONFIG_TEXT: dnf update 'kernel*'
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
CONFIG_TEXT: dnf config-manager --disable almalinux-testing
Once promoted to production repositories, a plain update is sufficient:
CONFIG_TEXT: dnf update 'kernel*'
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
CVSS v3.1: 7.8 (Important). Patches are not yet available. Apply the temporary mitigation at the bottom of this article while waiting.
For the ESP/XFRM variant specifically, an alternative mitigation for systems that cannot disable the esp4/esp6 modules (e.g. servers running IPsec) is to disable unprivileged user namespaces, since exploitation relies on creating user and network namespaces:
CONFIG_TEXT: echo 0 /proc/sys/user/max_user_namespaces
Note: This may affect containers and other workloads that depend on unprivileged user namespaces. Test before applying in production.
Refer to the Red Hat Security Bulletin for current patch status and further guidance:
https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
To apply updates once available:
CONFIG_TEXT: dnf update 'kernel*'
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
No patched kernels are available yet; all supported releases (18.04 through 24.04) are currently under evaluation. Apply the temporary mitigation at the bottom of this article while waiting.
Refer to the Ubuntu blog for mitigation details:
https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
Check the Ubuntu security tracker for patch availability:
https://ubuntu.com/security/CVE-2026-43284
To apply updates once available:
CONFIG_TEXT: apt update
CONFIG_TEXT: apt upgrade
CONFIG_TEXT: reboot
CONFIG_TEXT: uname -r
Temporary mitigation
Until a patched kernel or KernelCare livepatch is installed, blacklist the esp4, esp6, and rxrpc modules to prevent them from loading, and unload them if already present:
# 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"
What these modules are and how disabling them affects the server:
CONFIG_TEXT: esp4 / esp6 — Kernel-side ESP transforms used by IPsec. On a typical hosting server these are not used, so disabling them has no practical impact. Warning: Do not apply this mitigation on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels, as it will interrupt that VPN connectivity.
CONFIG_TEXT: rxrpc — The AF_RXRPC transport used almost exclusively by AFS (Andrew File System) clients. Not present on typical hosting servers; disabling it has no impact on standard hosting workloads.
This mitigation does not require a reboot and can be reversed at any time after a patched kernel is installed:
# rm /etc/modprobe.d/dirtyfrag.conf
Drop page cache after mitigating
The exploit can modify legitimate system binaries in the page cache before gaining root. If the server was potentially targeted before the mitigation was applied, drop the page cache after mitigating:
# echo 3 /proc/sys/vm/drop_caches
Imunify360 users
IOCs associated with this exploit have been identified and the related script has been blacklisted in Imunify360. This is an additional layer of defense — it does not replace the kernel update.
Comments
1 comment
Hi,
This:
echo 3 /proc/sys/vm/drop_caches
Must be:
echo 3 > /proc/sys/vm/drop_caches
Regards
Roberto
Please sign in to leave a comment.