DirtyDecrypt PoC increases the risk of climbing privileges in kernel near the mainline

A public concept test that takes advantage of a recently corrected vulnerability in the Linux kernel rxgk module increases the risk for systems that run kernel very close to the main tree: the so-called explosion DirtyDecrypt (or DirtyCBC) allows an attacker with local access to become root in certain system configurations.

The technical root of the problem, according to the researchers who published the PoC, is a pagecache writing caused by the lack of a copy-on-write (COW) check on the rxgk _ decrypt _ skb function: in simple terms, kernel code ended up writing where it should not be on shared data, which opens the door to climbing privileges. The V12 team published the PoC and explains the details in its repository ( V12 PoC: DirtyDecrypt), and the description fits the correction recorded in the NVD as CVE-2026-31635.

It is important to highlight two factors that have an impact: first, the holding requires that the kernel be compiled with the enabled CONFIG _ RXGK option (i.e. RxGK support for AFS / rxrpc); therefore, it only affects distributions that follow closely the kernel upstream - for example, Fedora, Arch or OpenSUSE Tumbleweed - or systems with custom kernel including that module. Second, the vector is local: an attacker needs to run code on the machine previously (e.g. through a compromised user account or a malicious process with limited capabilities) to climb to root.

The existence of a public PoC changes the risk threshold: before it was a corrected failure in upstream, now any adversary with local access and basic knowledge could reuse the test to take full control of the system if the patch is not applied. This pattern is not new: in recent weeks there have been root-climbing failures of the same family (Dirty Frag, Fragnesia, Copy Fail) and organisms such as the CISA have already warned and listed vulnerabilities exploited in the known catalogue ( CISA Known Exploited Vulnerabilities), which shows a wave of active exploitation against kernel vectors.

What administrators and users should do: update the kernel to the version containing the correction as soon as possible; for production environments where immediate updating is not practical, apply temporary mitigation and control local access. A previously used mitigation against similar failures is to avoid the loading of the modules involved by creating a rule in / etc / modprobe.d that prevents their installation, downloading the modules and emptying chunks; be aware that this measure can break IPsec and distributed AFS file systems. If you adopt it, try it first in controlled environments and understand the impact on connectivity and services.

In addition to patching or mitigating, check telemetry and system integrity: look for signs of escalation of privileges or persistence (unexpected root sessions, new SUID binary sessions, abnormal processes with UID 0, changes in / etc, suspicious entries in dmesg or syslog). If you have kernel or EDR detection, check rxgk-related events or atypical pagecache operations; if you do not have these tools, consider deploying controls that limit local access and improve user and service segmentation.

For equipment that manage large fleets, you value applying security backports offered by the distribution, using livepatch services where they are available and prioritizing the updating of kernel in bastions or machines with multiple user accounts. Maintain a response process that includes isolation of suspicious hosts, collection of evidence and restoration from clean known backups when necessary.

Responsible disclosure and public evidence also remind us of an operational lesson: the vulnerabilities in kernel space, though local, are very valuable for attackers with initial access and accelerate lateral movement and persistence. Review kernel compilation options on critical machines (e.g. by consulting the kernel configuration or supplier packages to see if CONFIG _ RXGK is active) helps prioritize patches and mitigations with technical criteria.

If you want to deepen the technical resources and the original notices, see the PoC of the V12 team in GitHub ( https: / / github.com / v12-security / pcs / tree / main / dirtydecrypt) and the NVD input for correction ( https: / / nvd.nist.gov / vuln / detail / CVE-2026-31635). For policies and monitoring of exploited failures in the ecosystem, the CISA base is a useful reference ( https: / / www.cisa.gov / knowledge-exploited-vulnerabilities-catalog).

In short: already park, reduce non-essential local access, monitor commitment indicators and prepare a response plan. Public availability of PoC requires that, without mitigation or correction, the likelihood of exploitation will increase rapidly.