Dirty Frag Linux Kernel Vulnerability: What You Need to Know and How to Fix It

Last updated: 9 May 2026

Summary

A Linux kernel local privilege escalation vulnerability known as Dirty Frag has been disclosed. It is tracked mainly as:

• CVE-2026-43284: IPsec ESP / esp4 / esp6
• CVE-2026-43500: RxRPC / rxrpc

Dirty Frag may allow a local unprivileged user to gain root privileges. It is not a direct remote network exploit, but it is serious for hosting servers because an attacker may first gain limited access through a compromised website, SSH/SFTP account, container workload, or local user account. cPanel confirms that the issue affects the Linux kernel itself and is present across multiple Linux distributions. (cPanel Support)

---

Affected systems

Dirty Frag affects multiple Linux distributions and kernel streams. Confirmed affected platforms include:

• AlmaLinux 8, 9, 10
• Rocky Linux 8, 9, 10
• CloudLinux 7 Hybrid, 8, 9, 10
• Red Hat Enterprise Linux 8, 9, 10
• Ubuntu 20.04, 22.04, 24.04 and other supported Ubuntu releases
• Oracle Linux systems using affected RHCK or UEK kernels
• Other Linux distributions using affected kernel versions

CloudLinux confirms that CloudLinux 7 standard is not affected, while CloudLinux 7 Hybrid, 8, 9 and 10 are affected. CloudLinux 9 and 10 use the AlmaLinux kernel stream. (CloudLinux Blog)

---

Required action

The recommended fix is to install the vendor-patched kernel and reboot the server.

Check the current kernel:

uname -r

After updating and rebooting, verify again:

uname -r

Installing the kernel package alone is not enough. The server must boot into the patched kernel.

---

OS-specific update instructions

AlmaLinux 8 / 9 / 10

Update the kernel:

dnf clean metadata
dnf update 'kernel*' -y
reboot

Verify:

uname -r
rpm -q kernel

Expected patched versions:

AlmaLinux 8:  kernel-4.18.0-553.123.2.el8_10 or newer
AlmaLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

AlmaLinux confirms these patched kernel versions in its Dirty Frag advisory. (AlmaLinux OS)

---

CloudLinux

CloudLinux 7 Hybrid / 8

If the patched kernel is available in stable repositories:

yum update 'kernel*' -y
reboot
uname -r

If the patched kernel is only available in the testing/beta repository:

For CloudLinux 8:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*' -y
reboot
uname -r

For CloudLinux 7 Hybrid:

yum --enablerepo=cl7h_beta update 'kernel*' -y
reboot
uname -r

Expected patched versions:

CloudLinux 7 Hybrid: kernel-4.18.0-553.123.2.lve.el7h or newer
CloudLinux 8:        kernel-4.18.0-553.123.2.lve.el8 or newer

CloudLinux lists these target versions for the CL7h and CL8 patched kernel streams. (CloudLinux Blog)

---

CloudLinux 9 / 10

CloudLinux 9 and 10 use the AlmaLinux kernel stream. If the patched kernel is available from stable repositories:

dnf update 'kernel*' -y
reboot
uname -r

Expected patched versions:

CloudLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
CloudLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

If the patched kernel is not yet visible from stable repositories or local mirrors, use the AlmaLinux testing repository temporarily.

For CloudLinux 10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
dnf update 'kernel*' -y
reboot

After reboot:

uname -r
dnf config-manager --disable almalinux-testing

For CloudLinux 9:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm
dnf update 'kernel*' -y
reboot

After reboot:

uname -r
dnf config-manager --disable almalinux-testing

Only use the testing repository to update the kernel packages, then disable it immediately after verification. CloudLinux documents this temporary testing-repository flow for CL9 and CL10. (CloudLinux Blog)

---

RHEL / Rocky Linux / Oracle Linux

For RHEL-family systems:

dnf clean all
dnf update 'kernel*' -y
reboot

For Oracle Linux systems using UEK, also update UEK packages:

dnf update 'kernel*' 'kernel-uek*' -y
reboot

Verify:

uname -r
rpm -q kernel kernel-core kernel-uek 2>/dev/null

Red Hat confirms Dirty Frag affects RHEL 8, 9, 10 and OpenShift 4, and recommends kernel updates or mitigation depending on patch availability. (Red Hat Customer Portal)

---

Ubuntu / Debian

Update the system kernel:

apt update
apt full-upgrade -y
reboot

Verify:

uname -r
dpkg -l | grep linux-image

Ubuntu confirms the fix is delivered through Linux kernel image packages and recommends rebooting into the updated kernel. (Ubuntu)

---

SUSE / openSUSE

Update the kernel:

zypper refresh
zypper update kernel-default
reboot

Verify:

uname -r
rpm -qa | grep kernel

---

Temporary mitigation

If a patched kernel or livepatch is not yet available, block the affected modules:

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

rmmod esp4 esp6 rxrpc 2>/dev/null || true

Verify:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

This mitigation blocks esp4, esp6, and rxrpc, which are the affected kernel module paths. CloudLinux, Ubuntu, and Red Hat all document this module-blocking approach as temporary mitigation. (CloudLinux Blog)

---

Important warning

Do not apply this mitigation without review on systems using:

• IPsec
• StrongSwan
• Libreswan
• VPN gateways
• AFS / RxRPC workloads

Blocking esp4 and esp6 can break IPsec traffic, and blocking rxrpc can affect AFS/RxRPC workloads. Ubuntu and Red Hat both note this operational impact. (Ubuntu)

---

Ubuntu / Debian additional step

On Ubuntu and Debian systems, regenerate initramfs after applying the mitigation:

update-initramfs -u -k all

Then verify again:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Ubuntu recommends regenerating initramfs so the affected modules remain blocked during boot. (Ubuntu)

---

Drop page cache after mitigation

After applying mitigation, drop page cache:

sync
echo 3 > /proc/sys/vm/drop_caches

CloudLinux notes that the exploit can modify legitimate system binaries in page cache, so dropping page cache is recommended after mitigation on potentially targeted systems. (CloudLinux Blog)

---

Remove mitigation after patching

After the patched kernel is installed and the server has rebooted into it:

rm -f /etc/modprobe.d/dirtyfrag.conf

For Ubuntu / Debian:

update-initramfs -u -k all

Reboot if required:

reboot

---

KernelCare

If KernelCare is installed:

kcarectl --update

Verify coverage:

kcarectl --patch-info | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag'

If the CVE does not appear in the output, KernelCare may not yet cover the running kernel. In that case, apply the vendor kernel update or temporary mitigation. cPanel and CloudLinux both reference KernelCare as an available livepatch path where coverage exists. (cPanel Support)

---

Verification checklist

Run the following after patching or mitigation:

cat /etc/os-release
uname -r

For RHEL-family systems:

rpm -q kernel kernel-core kernel-uek 2>/dev/null

For Ubuntu / Debian:

dpkg -l | grep linux-image

Check affected modules:

lsmod | grep -E 'esp4|esp6|rxrpc'

Confirm mitigation status:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

---

EuroVPS recommendation

Restrict unnecessary SSH, SFTP, shell and panel access, review the server for compromised websites, unexpected local users or privilege escalation, and migrate end-of-life operating systems.

---

Need assistance?

Open a support ticket from the Client Area and, on servers where we have root access, our engineers will patch or mitigate and verify the fix.