Dirty Frag (CVE-2026-43284, CVE-2026-43500): Mitigation and Kernel Update on CloudLinux

A week after Copy Fail (CVE-2026-31431), researcher Hyunwoo Kim disclosed a second Linux kernel local privilege escalation in the same broad area — IPsec ESP and rxrpc — and named it Dirty Frag. A working public proof-of-concept exists; any unprivileged local user can use it to gain root in a single command.

The flaw is in the in-place decryption path of esp4, esp6, and rxrpc. When the receive path decrypts over paged buffers not privately owned by the kernel (e.g., pipe pages reaching the socket via splice(2) / sendfile(2)), unprivileged processes can retain references to the resulting plaintext — yielding a write primitive into the page cache that the public PoC turns into root in a single command.

Per Hyunwoo Kim’s public disclosure on oss-security (2026-05-07), the responsible-disclosure embargo was broken before distributions could coordinate, so no CVE identifiers have been allocated at the time of publication for either of the two bugs that make up Dirty Frag, and a working exploit is now publicly available.

Update on CVE assignments:

• The xfrm-ESP Page-Cache Write vulnerability has been assigned CVE-2026-43284
• The RxRPC Page-Cache Write vulnerability has been reserved as CVE-2026-43500 for tracking (NVD entry pending publication)

Details: public PoC and write-up · Dirty Frag disclosure · AlmaLinux announcement · NVD entry

Affected CloudLinux versions

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/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /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 page-cache 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

Update instructions

dnf update 'kernel-lts*' --enablerepo=cloudlinux-updates-testing
reboot

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)

yum install --enablerepo=cloudlinux-rollout-4-bypass packageName
reboot

Both CL7h and CL8 will be CloudLinux rebuilds of the upstream fix.

Updating from the CloudLinux beta channel

Once the patched kernel lands in the beta channel, enable it for a single update:

Instructions for CL8 — beta channel cloudlinux-updates-testing:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
reboot
uname -rInstructions for CL7h — beta channel cl7h_beta:

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

Once the kernel reaches the stable channel

A plain update will pull the patched version, no extra repo enablement needed:

yum update 'kernel*'
reboot
uname -r

Stream 2 — AlmaLinux kernel (CL9, CL10)

CloudLinux 9 and CloudLinux 10 use the AlmaLinux kernel directly. 

Updating from the AlmaLinux testing repository

The almalinux-release-testing package is not in CloudLinux repositories — install it from a direct URL, update the kernel, then disable the testing repo.

For CL10:

# 1. Enable the AlmaLinux 10 testing repo
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm

# 2. Update the kernel
dnf update ‘kernel*’

# 3. Reboot
reboot

# 4. Verify — expected kernel-6.12.0-124.55.2.el10_1 or later
uname -r

# 5. Disable the testing repo
dnf config-manager –disable almalinux-testingFor CL9 — same flow, but replace the URL in step 1:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpmExpected version: kernel-5.14.0-611.54.3.el9_7 or later.

Once the kernel reaches AlmaLinux stable production repositories

A plain update will pull the patched version, no testing-repo step needed:

dnf update 'kernel*'
reboot
uname -r

Stream 3 — KernelCare livepatch (all affected versions)

kcarectl --update --prefix test

kcarectl --update --prefix test

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
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

References