Dirty Frag - Another Linux root exploit. Apply this fix now

Announcements
,
1

One week after Copy Fail, another Linux kernel vulnerability just dropped. This one is called Dirty Frag. The embargo was broken early so there is no official patch, no CVE number yet, and a working exploit is already public.

If you applied the Copy Fail fix last week, that does not cover you here. Dirty Frag is a completely different attack path. You need a separate fix.

Not familiar with Copy Fail? Catch up here first: CVE-2026-31431 Copy Fail — What happened, what we did, and what you need to do

What is Dirty Frag?

Dirty Frag chains two Linux kernel bugs to give any unprivileged user with shell access full root on your server. No race conditions, no special tools, no timing tricks. It works on the first attempt every time.

It targets three kernel modules: esp4, esp6 and rxrpc. Ubuntu is particularly exposed because rxrpc loads automatically on Ubuntu while most other distributions do not ship it by default.

:warning: The Copy Fail fix does not protect you from this. Even if you followed our Copy Fail advisory and blocked algif_aead last week, your server is still vulnerable. This needs its own fix.

What we decided

We evaluated pushing this mitigation through the RunCloud agent but decided against it. Unlike Copy Fail, this fix disables three kernel modules and could impact servers running IPsec VPN tunnels or AFS. We did not want to risk breaking production servers without the owner knowing.

This one is on you to apply manually. It takes one command and under a minute.

Before you apply, check if the modules are in use

Run these first and read the output before doing anything:

# Check if any of the three modules are currently loaded
grep -E 'esp4|esp6|rxrpc' /proc/modules

# Check if anything is actively using them
lsof 2>/dev/null | grep -E 'esp4|esp6|rxrpc'

# Check if IPsec is configured on this server
ip xfrm policy list
ip xfrm state list

# Check if anything is using rxrpc
ss -a | grep rxrpc

How to read the results:

  • All empty means nothing is loaded or in use. Safe to apply.
  • grep /proc/modules has output but lsof is empty means modules are loaded but idle. Still safe to apply.
  • ip xfrm returns active policies or states then you have IPsec running. Applying the fix will drop those tunnels. Understand what breaks before you proceed.

If all checks come back empty, you are good to go.

Apply the fix

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"

This blocks all three modules from loading and unloads them immediately. The fix survives reboots.

:rocket: Reboot is the cleanest option. It ensures the mitigation is fully in effect and avoids any risk of a cache spike. If you can reboot, do that instead.

reboot

If you cannot reboot right now, you can drop the page cache as an alternative to make the mitigation take effect at runtime:

echo 3 > /proc/sys/vm/drop_caches

:warning: Only do this if you cannot reboot. Dropping page cache flushes cached file data from memory. On a busy server this can cause a temporary spike in disk I/O as the cache rebuilds. Your server stays up but expect a brief slowdown. A clean reboot is always the better option.

:white_check_mark: Will this break my RunCloud stack? No. Nginx, PHP, MySQL, SSH and SSL are all unaffected. The only things that break are IPsec VPN tunnels using ESP mode and AFS. If you are not sure what those are, you are not using them.

:information_source: Run this with caution. Before applying, make sure you have completed the pre-checks above. If anything breaks after applying the fix, you can undo it immediately with:

sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo modprobe esp4
sudo modprobe esp6
sudo modprobe rxrpc

This restores all three modules. If the modules were in use before you removed them, a reboot after restoring may be required for dependent services to recover cleanly.

Verify it worked

grep -E 'esp4|esp6|rxrpc' /proc/modules

Empty output means all three modules are gone. You are protected.

Check your settings

Go to your server’s Auto Update settings and confirm the following is checked:

  • Enable Security Updates

This is what allows our agent to push fixes directly to your server. If it is off, we cannot reach you when it matters.

What comes next

No official Ubuntu kernel patch yet. The embargo broke early and Ubuntu has not had time to ship one. We are watching their tracker and will update this thread the moment something is available.

When the patch lands:

sudo apt update && sudo apt upgrade -y
sudo reboot

Then clean up the mitigation file:

sudo rm /etc/modprobe.d/dirtyfrag.conf

References

If you have questions, reply below or contact our support team directly. We will keep this updated as things develop.

7 Likes