Stop Local Linux Root Exploits with This Simple Kernel Module Workaround

 

Stop local Linux root exploits with a simple kernel module workaround. No patch yet? Block esp4, esp6, and rxrpc in minutes.

Worried that a local user—or a piece of malware—could take over your Linux server? Kernel vulnerabilities that allow privilege escalation are discovered often, and waiting for an official patch can leave you exposed for days.

In this post, you’ll learn a practical, immediate workaround to block a class of root exploits at the module level. By the end, you’ll be able to protect your systems before your distribution releases an update.

Understanding the Attack Surface: Decryption Fast Paths

Many local privilege escalation bugs live deep inside kernel subsystems that handle network protocols. One recent example affects the decryption fast paths of esp4, esp6 (IPsec Encapsulating Security Payload), and rxrPC (an in-kernel remote procedure call protocol). 

An attacker with a local account can trigger these flaws to gain full root access.

You don’t need to memorize those names. What matters is that these modules are not essential for most production servers—unless you specifically use IPsec VPNs or RxRPC-based services (like some network filesystem setups). 

For a typical web server, database host, or container host, removing these modules causes zero disruption.

The Immediate Workaround: Blacklist and Unload

Because no official patches are available yet for many distributions, you can apply a simple module-blocking workaround. The idea: prevent the kernel from loading the vulnerable modules entirely. This stops any exploit from reaching the buggy code.

Run the following command as root:

bash

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"

Here’s what it does step by step:

• Creates a file in /etc/modprobe.d/ that tells the kernel to run /bin/false (which fails) whenever someone tries to load esp4, esp6, or rxrpc.

• Immediately removes (rmmod) those modules if they are already loaded.

• The 2>/dev/null hides harmless “module not found” errors.

After this command, your system will no longer load those three modules—even after a reboot. Any exploit relying on them becomes useless.

When Is This Workaround Safe?

Before applying any change, verify that your services don’t depend on these modules. For most Linux servers, they are not loaded by default. You can check with:

bash

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

If you see no output, you are safe to apply the workaround. If you do see one of them listed, ask yourself: “Do I run an IPsec VPN (like StrongSwan, LibreSwan) or an RxRPC-based service?”

• Example 1: A company’s internal web server—no IPsec, no RxRPC → apply the workaround without worry.

• Example 2: A VPN gateway that uses IPsec with esp4 → do not apply; wait for a proper kernel update instead.

For systems where these modules are not needed, the workaround closes the vulnerability instantly.

Making It Permanent and Verifying

The command above already creates a persistent configuration. After rebooting, confirm that the modules stay gone:

bash

lsmod | grep -E "esp4|esp6|rxrpc"
modprobe --show-config | grep -E "esp4|esp6|rxrpc"

You should see install esp4 /bin/false (and similar lines) in the modprobe configuration. If you ever need to reverse the workaround (after a patched kernel arrives), just delete the file:

bash

rm /etc/modprobe.d/dirtyfrag.conf

Then reboot or manually reload the modules if required.

Actionable Tips You Can Try Today

• Check your exposure – Run lsmod | grep -E "esp4|esp6|rxrpc" on every production server. Note which systems have these modules loaded.

• Apply the workaround on servers that do not rely on IPsec or RxRPC. Use the one‑line command above—it takes five seconds.

• Test in a staging environment first. Clone a VM or container, apply the workaround, and verify your key applications still work.

• Monitor for official patches – Some enterprise distributions (like Alma Linux) have already released early test patches. Watch your distribution’s security announce list.

• Document the change – Add a comment in your /etc/modprobe.d/dirtyfrag.conf file explaining why it exists, so your team knows to remove it after a kernel update.

Conclusion

Blocking vulnerable kernel modules is a fast, effective defense against local privilege escalation when patches aren’t ready. 

By blacklisting esp4, esp6, and rxrpc, you remove the attack surface entirely for most common Linux workloads. This technique works for any similar vulnerability—not just this one. 

Try the workaround on a non‑critical system this week, and then roll it out to your servers. If you discover another non‑essential module causing trouble, you now know how to disable it safely.