Dirty Frag vulnerability reported for Linux kernel

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

KernelCare

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.

CloudLinux

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.

AlmaLinux

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

Red Hat Enterprise Linux / Rocky Linux

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

Ubuntu

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/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen’ > /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.