A proof-of-concept has been published for a vulnerability DirtyDecrypt, also known as DirtyCBC, allowing a local unprivileged user to gain root rights on certain Linux systems. The problem lies in the code rxgk subsystem RxRPC and is related to writing to the page cache due to a missing copy-on-write check in the rxgk_decrypt_skb() function. The PoC was reported by BleepingComputer on May 18, 2026; the PoC itself is hosted in the V12 team's repository.
RxRPC is a kernel-level networking protocol for Linux over UDP, providing reliable transport for remote operations. The kernel documentation specifically states that AFS — Andrew File System — is an example of an application using RxRPC, and the protocol supports security negotiations for connections. This area pertains to RxGK, which is used for the secure mode of RxRPC/AFS.
According to V12's description, DirtyDecrypt is another variant of vulnerabilities in the CopyFail / Dirty Frag / Fragnesiaclass. They all revolve around a similar idea: improper handling of kernel memory, page cache, and buffers can allow an unprivileged local process to affect data that should be inaccessible for writing. In the case of DirtyDecrypt, it concerns ‘rxgk pagecache write’ due to the missing COW protection in rxgk_decrypt_skb().
The V12 team claims to have discovered and reported the issue on May 9, 2026, but the maintainers responded that it was a duplicate of a previously fixed bug. Following this, the researchers published the PoC, arguing that the fix is already in the mainline kernel.
The situation with CVE looks somewhat convoluted. BleepingComputer writes that there is no separate official CVE specifically for the name DirtyDecrypt at the time of publication, but analyst Will Dormann connects the details released by V12 with CVE-2026-31635, fixed at the end of April. The NVD database describes CVE-2026-31635 as a bug in rxrpc: the rxgk_verify_response() function incorrectly checked the length of the RESPONSE authenticator, allowing an excessively large authenticator to reach rxgk_decrypt_skb() and trigger the code to BUG_ON(len).
That is, public publications link DirtyDecrypt with CVE-2026-31635, but the formal description of the CVE in the NVD currently appears narrower and primarily addresses the length checking bug in rxrpc rather than directly about the alias DirtyDecrypt/DirtyCBC as a separate entry. Therefore, it is more accurate to state that DirtyDecrypt likely corresponds to or is closely related to CVE-2026-31635, rather than claiming that this is the official CVE name.
A kernel with the option enabled is required for operation CONFIG_RXGK, which includes support for RxGK for AFS clients and network transport. This significantly narrows down the affected systems, primarily focusing on distributions that quickly follow the upstream kernel, including Alpine, Arch Linux and openSUSE Tumbleweed. At the same time, BleepingComputer emphasizes that the published V12 PoC was only tested on Fedora and the mainline kernel.
DirtyDecrypt emerged against the backdrop of a series of similarly classed Linux LPE vulnerabilities. Previously disclosed were Copy Fail in algif_aead, Dirty Frag in network components, and then Fragnesia in XFRM ESP-in-TCP. Microsoft described Dirty Frag as local privilege escalation via the esp4, esp6, and rxrpc components, allowing an attacker to gain root access after obtaining local access and establish a foothold in the system.
The practical danger of such flaws is that they are often exploited after the initial breach: for instance, after compromising an SSH account, web shell, vulnerable container, or low-privilege service user. Once root access is gained, an attacker can disable protections, read secrets, alter logs, deploy persistence, and move further through the infrastructure.
Users of potentially affected rolling-release distributions are advised to install the latest kernel updates. For systems where immediate updating is not possible, temporary measures such as disabling unused rxrpc modules and related components are mentioned in publications; however, such workarounds may break AFS and some IPsec/VPN scenarios, so they should only be applied after assessing the impact on the specific system.
For most desktop and server installations, the risk is likely lower than that of Copy Fail: DirtyDecrypt necessitates a specific kernel configuration and local code execution. Nevertheless, for Fedora, Arch Linux, openSUSE Tumbleweed, and other systems with rapid kernel updates, the issue merits attention: this is no longer a theoretical report, but a vulnerability with a published PoC and a clear path to privilege escalation.
Source: linux.org.ru
