Dirty Frag vulnerability reported for Linux kernel CVE-2026-43284, CVE-2026-43500

Rocky Linux Help & Support
, ,
1

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 later than 2017 (starting around Linux 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 uses when loading a binary.

As this is a new vulnerability disclosed today, May 7th, 2026, statements from many upstream maintainers of various Operating Systems have not yet been released.

Mitigation Steps:

At this time, we are waiting for the various kernel maintainers to provide a patch.

In the meantime, the vulnerability can be mitigated by disabling various Linux kernel modules if you don’t use IPsec or RxRPC:

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”

------------------------------------------------

Next, flush the kernel caches using the following command to ensure the binary page-cache is not modified:

----------------------------------------------

echo 3 > /proc/sys/vm/drop_caches

----------------------------------------------

2

See Rocky Linux Security Repository and Dirty Frag Security Update for our fix.

3

When tyring to enable the security repo. I just get Error: Unknown repo: 'security

Any suggestions?

4

Try updating the rocky-release package to the latest.

5

Thanks! That worked!

6

When the hotfixed (HF) kernel (5.14.0-611.54.1.el9_7.0.1.x86_64) from the new security repository was installed, after reboot I noticed that OS still using the previous kernel (5.14.0-611.54.1.el9_7.x86_64). I checked the kernel indices and found that the HF has index 1 and as workaround I tried to manually set the kernel version with grub2-set-default 1 and after reboot it worked. I suppose that manually setting the index position is not a good idea as it may affect future updates. Has anyone else seen this behavior with the new security repository? If so, do you have a better solution that doesn’t rely on hardcoded index positions?

7

Nope, all mine booted into the new kernel. Nothing extra was done. Just enabled the security repo and did dnf update.

8

What kernel version did you have before update? Was it also 5.14.0-611.54.1.el9_7.x86_64?

9

Yes, it was the same kernel version that you had.

10

I run dnf enablerepo=security update and the new kernel is now 5.14.0-611.54.1.el9_7.0.1.x86_64. I also noticed that the kernel 5.14.0-611.55.1.el9_7.x86_64 is also available. If I run dnf update on the system with 5.14.0-611.54.1.el9_7.0.1.x86_64 does not do any updates. Should we install the security update from the security repo or go straight with 5.14.0-611.54.1.el9_7.0.1.x86_64?

11

Kernel 5.14.0-611.55.1.el9_7.x86_64 is the official kernel that was fixed in RHEL. The 5.14.0-611.54.1.el9_7.0.1.x86_64 is from the security repo and the backported fix until the official fix came from RHEL. You should use the latest kernel so 5.14.0-611.55