how a missing copy-on-write guard broke the linux kernel security model

A multi-million dollar defense strategy usually relies on the assumption that the core operating system kernel is a static, impenetrable vault. We spend years refining firewall rules, identity providers, and endpoint detection scripts, yet the architectural foundation often remains the most fragile component. Linux uses an optimization called copy-on-write to manage memory efficiency. This system ensures that multiple processes share the same physical memory until one needs to modify it. At that point, the kernel is supposed to create a private copy to prevent the change from affecting other users. In the case of CVE-2026-31635, this basic promise failed.

I spent the last 48 hours reviewing the proof-of-concept code released for DirtyDecrypt, also known as DirtyCBC. The vulnerability is a textbook example of an architectural paradox. The very mechanism designed to make the Linux kernel fast and memory-efficient is the mechanism that allowed an unprivileged user to overwrite root-owned files. This is the third major variation of this specific memory corruption logic we have seen in as many months. It reminds me of a ship built with a hull that is impenetrable from the outside but dissolves when it touches its own internal fuel.

the mechanics of the rxgk pagecache vulnerability

The defect exists within the rxgk_decrypt_skb function. This code handles the decryption of incoming socket buffers on the receive side of the network stack. When the kernel processes these buffers, it handles memory pages that are sometimes shared with the page cache of other processes. Under normal conditions, the Linux kernel triggers a copy-on-write operation before any write occurs on a shared page. This prevents data from one process from bleeding into the memory space of another.

Zellic researchers discovered that rxgk_decrypt_skb lacked this COW guard. When the kernel decrypts data into a buffer that happens to be a shared page, it writes the decrypted contents directly into the physical memory without making a private copy first. This bypasses the standard file system permissions and memory protections. An attacker can map a sensitive file like /etc/shadow or a SUID binary into their memory space and then use the vulnerable network path to force the kernel to write data into that file's page cache. Once the kernel flushes the page cache to disk, the modification becomes permanent.

tracing the lineage from copy fail to dirtydecrypt

DirtyDecrypt is not an isolated incident. It is a descendant of a family of vulnerabilities that began with Copy Fail (CVE-2026-31431) in April 2026. Researchers at Theori first identified that the cryptographic socket interface in the kernel had similar logic flaws. A week later, Dirty Frag emerged. This was followed by Fragnesia, which targeted the XFRM subsystem. Each of these vulnerabilities shares the same root cause: a failure to verify page ownership before performing kernel-level writes.

This sequence of disclosures highlights a systemic issue in how the Linux kernel handles modern network memory optimizations. The introduction of MSG_SPLICE_PAGES and other high-performance zero-copy mechanisms has introduced complexity that the current COW infrastructure struggles to regulate. The researcher known as 0xdeadbeefnetwork noted that once a fix for one variant lands in the public tree, weaponizing the next variant is a standard exercise for security professionals. This rapid cycle of n-day development is a reminder that a patch in one subsystem does not guarantee the safety of another that uses similar logic.

why specific distributions remain in the line of fire

The impact of CVE-2026-31635 depends heavily on the kernel configuration. The vulnerability requires the CONFIG_RXGK option to be enabled. This is why distributions like Fedora, Arch Linux, and openSUSE Tumbleweed are at higher risk. These distributions often favor cutting-edge features and broader hardware support, which includes enabling specialized networking and cryptographic modules that are disabled in more conservative enterprise releases like RHEL or Debian Stable.

In cloud environments, this vulnerability presents a significant risk to container isolation. If a worker node runs a vulnerable kernel, a compromised container can use the DirtyDecrypt primitive to escape its local environment. By overwriting the page cache for shared binaries or kernel structures, the attacker can move from a restricted pod to full root access on the host. This effectively collapses the multi-tenant security model that Kubernetes and other orchestrators rely on for workload isolation.

the killswitch debate and the future of kernel patching

The volume of kernel disclosures has forced a rethink of how we manage Linux security. Sasha Levin, a prominent kernel maintainer, recently proposed a kernel killswitch. This tool allows an administrator to disable a specific kernel function at runtime without a reboot. If a zero-day vulnerability like DirtyDecrypt is discovered in a specific network function, the administrator can tell the kernel to stop executing that function and return a fixed value instead. This acts as an emergency shutoff valve for the ship's hull while a permanent patch is prepared.

Some developers worry about the security implications of the killswitch itself. If an attacker gains enough privilege to engage the killswitch, they could theoretically disable security modules or auditing functions. However, the current reality of the Linux ecosystem is that patching is too slow for the speed of modern exploit development. The killswitch provides a reactive measure for organizations that cannot wait for a full regression test of a new kernel version. It is a pragmatic response to the fact that our software is increasingly too complex to be bug-free.

rocky linux and the move toward accelerated security fixes

Rocky Linux has taken a different approach by introducing a dedicated security repository. Traditionally, downstream distributions wait for upstream providers to release a vetted patch before they ship updates to their users. This creates a window of vulnerability when a PoC is public but the official update is stuck in a QA cycle. The new Rocky Linux security repository is an opt-in feature that ships urgent fixes as soon as they are available, even if they have not yet reached the mainline kernel.

This move is controversial because it breaks strict upstream compatibility. If the Rocky Linux team patches a bug and the upstream maintainers later choose a different fix, the two kernels will diverge. The maintainers acknowledge this risk but believe the protection of their users is more important than perfect version alignment. This reflects a broader shift in the industry toward prioritizing agility in the face of active exploitation. For administrators, it means a choice between the stability of the traditional release cycle and the resilience of a more aggressive patching strategy.

mitigating risk in containerized and bare-metal environments

Defending against CVE-2026-31635 requires more than just a standard update. Organizations must first verify if their systems are even vulnerable. Checking the kernel configuration for CONFIG_RXGK is the first step. If the module is enabled but not required for your workload, disabling it via a kernel module denylist is the most effective immediate mitigation. This removes the attack surface entirely without the need for a reboot in some cases.

From a risk perspective, you should assume that local users have the capability to execute this PoC if they have shell access. This makes strict monitoring of the /etc/ directory and SUID binaries essential. Modern security tools that monitor page cache integrity can alert you if a process attempts to modify read-only files through unconventional memory paths. Patching remains the gold standard, but until your fleet is updated, restrictive Seccomp profiles and AppArmor policies can limit the ability of local processes to interact with the vulnerable network functions.

Audit your kernel configuration and verify if your distribution has released a fix for CVE-2026-31635. Organizations running Arch or Fedora should prioritize these updates immediately. If you manage a large fleet of Linux servers, consider the long-term implications of using kernels with broad feature sets and evaluate if a more hardened, minimal kernel configuration is appropriate for your security posture.

Sources

• NIST National Vulnerability Database (NVD) CVE-2026-31635 Record
• Linux Kernel Mailing List (LKML) Killswitch Proposal by Sasha Levin
• Zellic and V12 Security Technical Report on DirtyDecrypt
• Rocky Linux Security Repository Documentation
• MITRE ATT&CK Framework: Exploitation for Privilege Escalation (T1068)

Disclaimer: This article is for informational and educational purposes only. It does not replace a professional cybersecurity audit or incident response service. The technical details provided are intended to help administrators understand the risks and implement necessary defenses.