Two vulnerabilities have been identified in the Linux kernel, which are essentially analogous to the recently disclosed Copy Fail vulnerability, but manifest in different subsystems \u2014 xfrm-ESP and RxRPC. The vulnerabilities have been assigned the codename Dirty Frag (also referred to as Copy Fail 2). These vulnerabilities allow an unprivileged user to gain root rights by overwriting process data in the page cache. An exploit is available that works on all current Linux distributions. Information about the vulnerability was disclosed prior to the publication of fixes, but a workaround is available to mitigate the issue. <\/p>\n
Dirty Frag encompasses two distinct vulnerabilities: the first in the xfrm-ESP module, which is used to accelerate encryption operations in IPsec using the ESP (Encapsulating Security Payload) protocol, and the second in the RxRPC driver, which implements the AF_RXRPC socket family and the corresponding RPC protocol that operates over UDP. Each vulnerability allows for obtaining root access individually. The xfrm-ESP vulnerability has been present in the Linux kernel since January 2017, while the RxRPC vulnerability has been present since June 2023. Both issues are caused by optimizations that allow direct writing to the page cache. <\/p>\n
To exploit the vulnerability in xfrm-ESP, the user must have permissions to create namespace spaces, and to exploit the vulnerability in RxRPC, there must be the ability to load the kernel module rxrpc.ko. For example, in Ubuntu, AppArmor rules prevent unprivileged users from creating namespace spaces, but the rxrpc.ko module is loaded by default. Some distributions lack the rxrpc.ko module, but do not block the creation of namespace spaces. The researcher who identified the issue has prepared a combined exploit capable of attacking the system through both vulnerabilities, allowing it to exploit the problem across all major distributions. The exploit has been confirmed to work on Ubuntu 24.04.4 with kernel 6.17.0-23, RHEL 10.1 with kernel 6.12.0-124.49.1, openSUSE Tumbleweed with kernel 7.0.2-1, CentOS Stream 10 with kernel 6.12.0-224, AlmaLinux 10 with kernel 6.12.0-124.52.3, and Fedora 44 with kernel 6.19.14-300. <\/p>\n
As with the Copy Fail vulnerability, the issues in xfrm-ESP and RxRPC are caused by the decryption of data in place using the splice() function, which transfers data between file descriptors and pipes without copying by passing references to elements in the page cache. Offsets for write operations were calculated without proper checks considering the direct reference to elements in the page cache, allowing specially crafted requests to overwrite 4 bytes at the chosen offset and modify the contents of any file in the page cache. <\/p>\n
All read operations from files first provide content from the page cache. In the case of modifications to data in the page cache, file read operations will return not the actual data stored on the storage but the substituted data. Exploiting the vulnerability involves altering the page cache for an executable file with the suid root flag. For example, to gain root rights, one can read the executable file \/usr\/bin\/su to place it in the page cache, after which they can insert their own code into the content loaded from that file in the page cache. Subsequently, running the \"su\" utility will lead to loading a modified copy from the page cache into memory instead of the original executable file from storage. <\/p>\n
The disclosure of information about vulnerabilities and the coordinated release of updates to address the issues was scheduled for May 12, but due to information leaks, the details of the vulnerability had to be published before the fixes were released. At the end of April, patches for rxrpc, ipsec, and xfrm were published on the public netdev mailing list without mentioning that they were related to addressing the vulnerability. On May 5, the maintainer of the IPsec subsystem accepted a change with a proposed fix in the xfrm-esp module into the netdev git repository, the description of which largely mirrored the description of the problem that led to the Copy Fail vulnerability in the algif_aead module. One security researcher became interested in this fix, managed to create a working exploit, and published it without knowing that a disclosure embargo was in place regarding the problem until May 12. <\/p>\n