Another local privilege escalation exploit. And, here's what CIQ did... again.

As the Head of Linux Engineering, yesterday was tough. My organization had done an amazing job resolving Copy Fail and pushing fixes out for all our kernel variants. I was catching up on Slack and saw a message saying that a new "Copy Fail"-like exploit was about to be made public. It is called Dirty Frag, and like Copy Fail, it lets an unprivileged local user become root through page cache manipulation. Instead of letting the team rest, I needed to spin them back up to protect our customers and support the community.

We are still in the middle of getting patches out to customers, and the process is very similar to what I described in my previous blog post. However, I want to talk a bit about the vulnerability itself, and then about how we view the bigger picture.

First, some details. Dirty Frag is actually two CVEs: CVE-2026-43284 in the kernel's esp modules (IPsec) and CVE-2026-43500 in the rxrpc modules. Both are local privilege escalation, not remote code execution. Exploiting them requires the attacker to already be running code on the box, so the threat profile is shared-tenancy environments and any system where untrusted code can run. Both let an unprivileged local user corrupt the page cache, and the published attack chain (released by V4bel on May 7) uses that write primitive to overwrite the /usr/bin/su binary in the page cache. Once the page-cached su is modified, any local user invoking su runs the modified binary out of cache and gets root without a password. The corruption persists in cache until the page is evicted or drop_caches is run.

Of the two, the esp modules are the urgent fire. They're used for IPsec communication and are loaded on virtually every Linux system, so the patch had to ship fast. Thankfully, it's the simpler of the two patches. The rxrpc module is a slower-moving second half. In Rocky Linux, the RPM containing it (kernel-modules-partner) lives in the [devel] repo, which isn't enabled by default, so most EL customers don't have rxrpc installed on the system at all. The rxrpc fix is also harder: there's no upstream patch yet, and discussion is still active on the netdev mailing list.

We have more details and current patch status in our knowledge base article: kb.ciq.com/article/rocky-linux/rl-dirty-frag-mitigation. Fixed kernels are already released or in flight for our supported products, and we're updating the KB as each one lands. The KB also walks through three mitigation paths for customers who can't take a kernel update right now.

The technical details matter for the patching cycle, but they're not what's keeping me up at night.

So what is causing me to lose sleep? We see Dirty Frag and the Copy Fail incident as a preview of what's coming. With the advent of AI tools that can scan and analyze codebases as large as the Linux kernel — millions of lines of code — we expect to see more exploits like these come in waves, with similar exploits following close behind. The strongest evidence we have is in the Dirty Frag disclosure itself: the researchers explicitly call out Copy Fail as the start of their research. The chain looks like this — a researcher finds a public vulnerability like Copy Fail, then uses AI to see if the same pattern exists elsewhere and where it would be most exploitable. The vulnerability is disclosed publicly, allowing other researchers (or AI) to identify the underlying pattern and look for similar exploits. In the days or weeks that follow, a new exploit — like Dirty Frag — hits an adjacent code path in the same vein as the previous one. While Dirty Frag's authors don't say whether AI was used to find it, we suspect it was. AI can scan and analyze source code across the kernel faster than humans, and it's good at recognizing complex patterns — exactly the kind of pattern recognition that surfaced Copy Fail. That sets up the conditions for waves of vulnerabilities like this for the foreseeable future.

So what should be done? We have some ideas, and we want to build on them with the broader community to help make everyone safer. That requires action across multiple groups. We need researchers to work with upstream in identifying issues. We need upstream communities to be more proactive in looking for similar vulnerabilities and working with OS vendors to implement fixes ahead of public disclosure. We need OS vendors to work quickly to provide updated packages to customers so that they can be protected. And we need users to build plans to make sure updates can be applied quickly and safely in their fleets. Together, we can keep each other protected from the waves of vulnerabilities that are sure to come.

Read the KB article