Linux Dirty Frag Vulnerability: VPS Recommendations
New critical Linux kernel vulnerabilities grouped under Dirty Frag have been disclosed. One is tracked as CVE-2026-43284, while the second is still awaiting CVE assignment. They allow local privilege escalation to root and affect multiple Linux distributions, including all supported Ubuntu versions listed by Canonical.
Local privilege escalation issues keep piling up on Linux. Earlier this week, we already published a news post about the Linux Copy Fail vulnerability, the measures applied at BoxToPlay, and recommendations for your VPS.
BoxToPlay has taken the necessary measures on its own internally managed infrastructure. The Ubuntu-recommended mitigation has already been deployed on the affected hosts wherever we are responsible for the systems. On the other hand, for our customers’ VPS instances, applying this mitigation and future kernel fixes remains the responsibility of each administrator of the guest system.
What Dirty Frag does
Dirty Frag actually groups two Local Privilege Escalation (LPE) vulnerabilities in Linux kernel modules:
- ESP modules (esp4 / esp6), used for IPsec/ESP (network encryption, VPNs);
- the RxRPC (rxrpc) module, used notably by the AFS distributed filesystem.
By abusing these modules, a local user can perform arbitrary writes into the kernel page cache and thereby take full control of the system (root). Canonical rates the severity as HIGH (CVSS 3.1: 7.8).
Dirty Frag affects:
- standard Linux hosts without containers: local privilege escalation to root;
- hosts running potentially untrusted containers: local privilege escalation and a potential additional risk of container escape.
The risk remains until the relevant kernel security updates are installed on the affected systems.
Ubuntu’s recommended temporary mitigation
Until patched kernel packages are available, Ubuntu recommends fully disabling the vulnerable modules so they cannot be loaded, and unloading them if already active.
The steps are as follows:
- Block future loading of esp4, esp6 and rxrpc via modprobe.d.
- Regenerate initramfs to prevent them from loading at boot.
- Unload already loaded modules.
- Verify that none of these modules are still present, and reboot if necessary.
1. Block the modules via /etc/modprobe.d/dirty-frag.conf
Create the configuration file that redirects their loading to /bin/false:
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
2. Update all initramfs images
sudo update-initramfs -u -k all
This step ensures the modules can no longer be loaded at startup.
3. Unload the modules if they are already loaded
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
4. Verify module status
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
Example output:
Affected modules are NOT loaded
If the modules remain loaded (message « Affected modules are loaded »), this means they are still being used by a service, for example an IPsec ESP VPN or AFS. In that case, the mitigation will only be fully effective after a reboot:
sudo reboot
Important: disabling ESP affects IPsec VPNs based on ESP and RxRPC, as well as AFS deployments. If your VPS environment depends on these services, we recommend carefully evaluating the impact before applying the mitigation on your own machines.
Remove the mitigation after a kernel update
Once the kernels are updated to a fixed version and rebooted, the temporary mitigation can be removed:
sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
What BoxToPlay has implemented on its own infrastructure
- The Ubuntu Dirty Frag mitigation has already been deployed on the relevant hosts of the infrastructure operated and directly administered by BoxToPlay.
- Active monitoring of Linux distribution security advisories to prepare the rapid deployment of patched kernels as soon as they become available on our relevant environments.
- When needed, planned reboots are then handled in a controlled way to finalize protection on our own systems.
Recommendations for your own VPS
BoxToPlay does not modify the guest system of self-managed VPS instances. We therefore strongly encourage administrators who manage their own systems to:
- apply the mitigation above on their Ubuntu-based distributions if they run potentially untrusted workloads;
- keep the kernel regularly updated as soon as official fixes are published;
- restrict shell access to trusted accounts and reinforce controls (logging, SSH keys, etc.).
Conclusion: keep your projects secure on our VPS servers
The Dirty Frag issue is a reminder of the importance of rigorous security follow-up on any Linux server. At BoxToPlay, we have taken the necessary measures on our own infrastructure, but every administrator must also secure the guest system of their VPS. If you want to try a flexible VPS environment, you can start your VPS server for free.