The Linux community faces a new critical vulnerability of local privilege escalation dubbed Dirty Frag, it was discovered just a week after the ruling Copy FailThis new security issue, explained in detail on GitHubThis allows any local user without privileges to gain root access on most current Linux distributions, and what's most worrying is that, for now, There is no official patch or assigned CVE identifier.
Dirty Frag has been revealed ahead of schedule following the breach of a security embargoA third party unrelated to the research leaked some of the information, prompting the researcher to publish technical details and proof of concept before kernel maintainers and distributions had patches ready. This leaves system administrators in a precarious situation: a reliably exploitable vulnerability with no definitive solution yet available.
What is Dirty Frag and why is it causing so much concern?
Dirty Frag has been presented as the direct successor to Copy Fail and belongs to the same family of vulnerabilities as Dirty Pipe. All these vulnerabilities share a common underlying principle: exploit errors in the kernel's page cache managementThat is, in the in-memory copy that Linux maintains of the files to improve performance.
In practical terms, the attack achieves that the kernel itself overwrites content in the page cache of a file without the attacker having write permissions to that file. This controlled overwrite becomes an arbitrary write primitive that, if properly exploited, allows privilege escalation to root with a single execution of the exploit.
According to South Korean researcher Hyunwoo Kim (known as @v4bel), Dirty Frag is not a simple one-off bug, but a logical vulnerability class which expands the same family to which Dirty Pipe and Copy Fail belong. It does not depend on time or race conditions, which means that the exploit is deterministic, does not cause kernel crashes in case of failure, and has a very high success rate in vulnerable systems.
Two vulnerabilities chained together to gain root access
One of the key features of Dirty Frag is that it's not based on a single failure, but rather It chains together two different Linux kernel vulnerabilities to achieve a near-universal attack on modern systems:
- xfrm-ESP Page-Cache Write – Vulnerability in the IPsec/ESP network stack (esp_input() function), introduced in a January 2017 commit (cac2661c53f3). Allows a 4-byte storage directly in the page cache, in a position and with a value controlled by the attacker.
- RxRPC Page-Cache Write – Failure in the RxRPC/rxkad subsystem (function rxkad_verify_packet_1()), present since June 2023It performs an 8-byte write to the page cache, leveraging the decryption process, without requiring privileges to create namespaces, and the key can be brute force completely from user space.
The first vulnerability is found in the IPsec (xfrm) subsystem and is exploited when a non-linear socket buffer with spliced ​​pages (pages in the page cache associated through operations such as splice(2) o sendfile(2)) evades copy verification by writing (skb_cow_data()In that scenario, the ESP fast decryption path writes directly to those pages, opening the door to modifying data that an unprivileged process references.
In the case of RxRPC, the decryption path applies an in-place decryption to pages in the page cache These are also "anchored" by the user, but without requiring special permissions such as the creation of namespaces. The attacker prepares an encrypted block in user space such that, when decrypted by the kernel, the result is exactly the desired writing in memory.
Why Dirty Frag affects almost all distributions
Neither vulnerability, taken separately, covers all scenarios. The xfrm-ESP exploit requires an unprivileged user to be able to create user namespacesThis is something that is blocked by AppArmor in some Ubuntu configurations. In contrast, the RxRPC exploit doesn't need namespaces, but the module does. rxrpc.ko is not included by default in most corporate distributions such as certain versions of RHEL.
The key to Dirty Frag is in use both exploitation paths in a complementary mannerIn systems where user namespaces are allowed, the ESP variant is triggered first; in environments like many Ubuntu installations, where namespace creation is limited but the rxrpc module is loaded by default, the RxRPC variant comes into play. Thus, The "blind spots" of one attack route are covered by the otherachieving a virtually universal exploit.
Among the distributions confirmed as affected are Ubuntu 24.04.4different versions of RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44 and openSUSE TumbleweedThis also applies to other popular platforms such as Arch Linux or WSL2 environments on Windows. In practice, this means that a large proportion of Linux servers and desktops in use may be vulnerable if they have the implicated modules and configurations.
Relationship to Copy Fail and other recent failures
Dirty Frag comes right after Copy Fail (CVE-2026-31431), which already forced accelerate patches across multiple Linux distributions in the face of a privilege escalation vulnerability that is being actively exploited. Both share the idea of ​​abusing the page cache and fast I/O paths, but Dirty Frag has a worrying advantage: It even works on systems where Copy Fail mitigations have been applied, such as the module lock algif_aead or policies of Kernel Lockdown.
The researcher points out that Dirty Frag can be triggered regardless of whether the algif_aead module is enabled or blockedIn other words, even if a production server has already implemented the Copy Fail recommendations, it remains vulnerable to this new exploit until the kernel is updated with the specific patches or the temporary mitigation measures are applied.
Impact on business environments
In the context where Linux is widely used in data centers, cloud providers, and government agencies.Dirty Frag poses a high risk of lateral escalation within internal networks. An attacker who gains normal user access (for example, through stolen credentials, a vulnerable web application, or a misconfigured service) I could get local root access immediately and without needing to exploit complex conditions.
For organizations that operate mission-critical services on distributions such as Ubuntu, RHEL, CentOS Stream, Fedora, or AlmaLinux, the problem is not limited to a single vendor: the vulnerability It resides in the Linux kernel itself.Some projects, such as AlmaLinux, have already started working on early patches for testingHowever, as of the date of publication, there is still no widely deployed official solution.
This scenario forces many security and systems teams to implement provisional measuresReview your server and workstation inventories, and prioritize environments with users who have interactive shells or the ability to run binaries on the system, and secure credentials (for example, change root password), since it is precisely the vector that Dirty Frag exploits.
Where is the kernel fault located?
On a technical level, Dirty Frag resides in the fast in-place decryption routes from the kernel's esp4, esp6, and rxrpc network modules. When a network packet arrives wrapped in ESP or via RxRPC, the receiving path attempts to decrypt it without additional data copies to gain performance.
The problem arises when those packages contain fragments of paged memory that are not exclusively owned by the kernel, such as pages in the page cache associated by operations of splice o MSG_SPLICE_PAGESInstead of working on a private buffer, the kernel write directly on those shared pageswhich are still referenced by an unprivileged user process. This exposes the plaintext of the data or, worse, allows for its deliberate corruption.
According to analyses published on security mailing lists such as oss-security and netdevThe January 2017 commit that introduced the xfrm-ESP vulnerability was also the root of a previous buffer overflow (CVE-2022-27666), suggesting that The same change in the code has generated several security problems in these years.
Absence of patches and breaking of the embargo
Dirty Frag was privately reported to the Linux kernel maintainers on April 30, 2026The original plan was to keep the information under embargo until mid-May to allow time to prepare patches, coordinate their release with distributions, and minimize the exposure window.
However, a third party unrelated to the coordination process published ESP exploit details on May 7breaking the embargo. Faced with this situation, the researcher decided to make the complete information public, including a Functional proof of concept capable of obtaining root with a single commandThe result is that most distributions and the rest of the world have been forced to react on the fly, without having solutions ready.
At the time of disclosure, There were no official patches in the main kernel tree Nor are there updated versions distributed by major vendors. Some providers, such as AlmaLinux, have released preliminary patches for internal testing, but administrators still rely primarily on configuration-level mitigation measures.
How to mitigate Dirty Frag while waiting for patches
In the absence of immediate updates, the general recommendation from the security community is block or disable the involved kernel modules in the ruling: esp4, esp6 y rxrpcThis prevents vulnerable routes from being loaded or used, drastically reducing the attack surface.
For most desktop systems and general-purpose servers, these modules they are not essentialsince they are primarily related to IPsec functionality (network traffic encryption) and RxRPC, a remote procedure call mechanism less common in standard deployments. However, in environments that use ESP-based IPsec VPNs or other specific services; disabling them may affect connectivity, and the risks should be assessed.
A quick and automated way to apply this mitigation is to create a modprobe configuration that forces the replacement of vulnerable modules with a harmless binary, and uninstalls them if they were already active. Various security sources have shared a command line similar to the following:
sudo sh -c "printf 'install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"This command creates the file /etc/modprobe.d/dirtyfrag.conf with rules that prevent modules esp4, esp6 y rxrpc Reload them, and then try to unload them if they were already in memory. For the vast majority of web servers, databases, or common business applications in infrastructures, It shouldn't cause interruptionsHowever, it is always recommended to test in pre-production environments first.
Proof of concept and real-world exploitation risk
Along with the public release of Dirty Frag, the researcher has published a repository with the proof of concept codeThis allows the exploit to be compiled and executed with a couple of commands. The resulting binary chains the two attack paths (ESP and RxRPC) and, on vulnerable systems, immediately elevates the current user to root.
Some technical sources that have analyzed the failure indicate that they have been able to reproduce the vulnerability in different distributionsThis includes updated Arch Linux installations and systems with the latest major kernel. It has even been observed that environments like WSL2, increasingly used by developers, exhibit the same behavior if the underlying kernel meets the necessary conditions.
The combination of an easy-to-use public exploit and a window without patches available This increases the likelihood that malicious groups will attempt to integrate Dirty Frag into their attack chains. For many organizations, this means urgently reviewing their access controls, strengthening internal network segmentation, and reinforcing monitoring for suspicious activity on Linux servers.
Distribution responses and next steps
Although the announcement caught much of the ecosystem by surprise, several Linux system providers have begun to work on specific patches for the affected decryption routesThe researcher himself sent the fix for the RxRPC part to the mailing list netdev by the end of April, and it is expected that solutions will be integrated into the stable branches of the kernel in the coming days or weeks.
In the case of distributions with a strong presence, such as Ubuntu, Debian, RHEL, SUSE, openSUSE, Fedora or AlmaLinuxThe focus is on delivering properly tested kernel updates through their usual security channels. Meanwhile, administrators and IT managers are urged to closely monitor security advisories Apply updates as soon as they are available in the official repositories.
Recent experience with Dirty Pipe, Copy Fail, and now Dirty Frag highlights the need for Improve security reviews in critical parts of the kernelespecially in high-performance areas such as fast network and I/O paths, where aggressive optimizations can introduce subtle but very dangerous errors.
The appearance of Dirty Frag, along with other recent bugs, once again highlights the importance of maintaining an agile update policy and defense-in-depth controls on any Linux infrastructure. Although there are still no definitive patches for this vulnerability, disabling the involved modules, monitoring systems, and preparing to quickly deploy future kernel updates has become, for now, the best contingency plan to minimize the impact of this new attack vector.
