Abstract:

During the two-week window from April 29 to May 13, 2026, the Linux kernel continuously disclosed three high-risk local privilege escalation vulnerabilities: Copy Fail (CVE-2026-31431), Dirty Frag (CVE-2026-43284, CVE-2026-43500) and Fragnesia (CVE-2026-46300). Together with the Dirty Pipe (CVE-2022-0847) disclosed in 2022, the three constitute a “Dirty family” vulnerability genealogy with strong intergenerational characteristics in the history of Linux kernel security: they all “pin” the cache page of read-only files into the kernel writable buffer by means of zero-copy path, and then realize stable writing to the page cache through in-situ operation of encrypted primitives without triggering dirty page write-back. This pedigree places three seemingly orthogonal engineering goals -“encryption mechanism, performance optimization and system security”- in a truly observable “three-body” coupling system: encryption should protect information, but in turn becomes an accurate and controllable tool for ultra vires writing; Performance optimization logic generally removes security contracts (skb_cow_data, out-of-place operations) to pursue hot path throughput, at the same time, the separation wall of memory ownership was dismantled. The original code security engineering system with “collapse point” and “memory destruction” as the default has almost failed to such “emergent logic vulnerabilities” accumulated across subsystems and years, and has revealed structural shortcomings under the impact of the new paradigm of “primitive hunting” for AI-assisted vulnerability mining. This report takes the Dirty family as an anatomical sample, carries out a dialectical analysis of the forward engineering perspective around the three paradoxes, and maps the concept of “executive governance” to the micro-defense-in-depth engineering practice for such emergent core defects in the conclusion part.

1. Introduction: The “Three-Body” Problem

In the process of following up and analyzing the major vulnerabilities of Copy Fail, Dirty Frag and Fragnesia series, Antiy engineers fell into thinking why the above vulnerabilities are coupled with the system encryption mechanism. Cryptographic protocols, as the cornerstone of security, have led to significant system security risks, but it is clear that this is not a conditional competition or conflict between the two security mechanisms, there is another key element-performance optimization. When the encryption mechanism, performance optimization and system security of Linux kernel are examined separately, their engineering logic is clear and self-consistent: the encryption standard defines the correct semantics of the algorithm, the performance optimization eliminates redundant copies, and the system security mechanism ensures memory isolation, but when the three are intercoupled, they cause complex chain risks. This naturally reminds us of a word-“three-body”.

“Three-body problem” is a famous problem in classical celestial mechanics. Since the establishment of Newtonian mechanics system, mathematicians have found that the motion of two celestial bodies under the action of universal gravitation can be accurately analyzed (Kaplerian orbit), but when there are three celestial bodies with mutual gravity in the system, their long-term motion shows chaotic characteristics, and stable analytical solution cannot be obtained-any small disturbance of initial conditions will lead to huge deviation of orbital behavior. This discovery can be traced back to Newton’s “Mathematical Principles of Natural Philosophy” in 1687, and the insolvability of the “three-body problem” was strictly proved by Henri Poincar in the late 19th century and became one of the classic examples of chaos theory of dynamic systems. In 2006, Chinese science fiction writer Liu Cixin’s novel “Three-Body” was published, which introduced the “three-body problem” from the academic field into the cultural context of science fiction. The term “three-body” has thus gained cultural vitality beyond its original meaning of physics in the context of the Chinese Internet-it no longer refers only to a mathematical problem, but also becomes a metaphor to describe the systematic dilemma of “three interacting variables cannot reach a stable equilibrium in chaos.

Therefore, this report borrows “three-body” and hopes to vividly represent the intersection and coupling of encryption mechanism, performance optimization and system security in the kernel architecture-encryption and performance intersect in the in-situ operation path, performance and security intersect in page cache sharing, and encryption and security intersect in the reinterpretation of memory semantics-the overall behavior presents the chaotic characteristics of “three-body” and unforeseen vulnerabilities emerge. We hope to reveal a long-neglected structural tension in the field of operating system kernel security-deep security flaws may not be the product of isolated code errors, but the systematic consequences of multiple rational designs emerging in nonlinear interactions. But at the same time, we also need to point out that this is just a “metaphor”, not a rigorous modeling or framework construction.

This report is not a new FAQ report or a single vulnerability review, but a summary of the series of documents of Antiy Research Institute. We have written the basic situation description, technical mechanism analysis, AI-assisted mining paradigm discussion and patched side effects tracking of single-point vulnerabilities in a series of reports respectively, such as “CVE-2026-31431 Fail (Copy Fail) Vulnerability FAQ (Part I)”, “CVE-2026-31431 Fail (Copy Fail) Vulnerability FAQ (Part II)”, “New Paradigm of Vulnerability Analysis for Human-AI Collaboration – Analysis of the Discovery Process of Copy Fail”, “Analysis of “Attack Primitives” Based on Dirty Frag Vulnerability Discovery Process – Re-discussion of Human-Computer Division of Work for Vulnerability Discovery and Analysis” and “Fragment Amnesia – How the Dirty Frag Patch Gave Rise to the Fragnesia Vulnerability”. The goal of this summary is to break out of a single point of vulnerability, from the kernel design philosophy and open source community operating mechanism level, the relevant complex factor relationship of structural law extraction, and this law is mapped to code security engineering and defense.

1.1 Origin of the event: Deep coupling of Dirty Family vulnerability and encryption mechanism

Since the disclosure of Dirty Cow (CVE-2016-5195) in October 2016, the Linux kernel “Dirty” series of vulnerabilities have gradually formed a family prototype with memory subsystem defects as common features. Dirty Cow, due to the race condition of the kernel copy-on-write (COW) mechanism, allows low-privilege users to tamper with read-only memory mapping and raise rights, affecting almost all Linux kernel versions after 2007, which is the foundational vulnerability of the family. In March 2022, Max Kellermann disclosed Dirty Pipe (CVE-2022-0847), focusing on page cache write path defects, which can overwrite read-only files and raise rights. In August of the same year, Dirty Cred (CVE-2022-2588) was made public at the Black Hat conference, exchanging privilege certificates through the kernel heap memory reuse mechanism to realize universal privilege raising without address dependency, further enriching the utilization paradigm of the family. Since then, the vulnerability class (bug class) with “Page Cache Write” as the common end point has gradually evolved from an isolated event to a family that can be named and normalized.

On April 29, 2026, the Xint Code research team of Theori, a South Korean security company, disclosed Copy Fail (CVE-2026-31431), officially introducing the family into a new stage of “encryption subsystem as a channel”; On May 7, South Korean researcher Hyunwoo Kim(@ v4bel) released the Dirty Frag document, combining two independent modules (xfrm-ESP and RxRPC) into a common rights-raising primitive in a chain complementary way. May 13, the William Bowling of the V12 Security team released another Fragnesia (CVE-2026-46300), which was described by Hyunwoo Kim as a derivative vulnerability “accidentally activated by Dirty Frag patch”. Since then, three high-risk vulnerabilities that have appeared in succession in a week have jointly formed the “vulnerability three companies” of the Dirty family “.

It is worth noting that this family is not a memory corruption vulnerability in the traditional sense-it does not rely on race conditions, does not trigger kernel panic, and does not need to adjust offsets from release to release. Its core mechanism is an improper combination of three engineering forces in the Linux kernel: zero copy (splice series interfaces) is used as a performance mechanism to introduce externally owned page cache pages into the kernel buffer, encryption paths (AF_ALG, xfrm-ESP, RxRPC/rxkad) cross the isolation boundary of buffer ownership in an in-place operation, and page cache (page cache) is trusted by default as a global writable resource shared across users/containers. This “three-force entanglement” feature makes the Dirty family have different anatomical value from the previous kernel LPE vulnerabilities at the level of engineering philosophy.

1.2 Core questioning: Encryption mechanism, performance, system security whether there is a competitive conflict

This report will focus on the following three paradoxes:

•     Paradox 1 (encryption as a negative and opposite of security gain and breeding destruction channel): encryption as an information security mechanism to protect the confidentiality, integrity and authenticity of information, should improve the overall security level of the system; However, Dirty family shows that the encryption subsystem has become an accurately controllable channel to destroy the integrity of the system page cache precisely because of its dual attributes of “cross-domain convergence” and “internal details cannot be audited.

•     Paradox 2 (zero-sum mutual exclusion between performance requirements and memory security): The engineering logic of performance optimization (splice zero copy, skb_cow_data omission, AEAD in-place operation, skb_try_coalesce merger) pursues “reducing copy and sharing ownership”, while the engineering logic of memory security pursues “post-copy operation and clear ownership”-behind every benefit of the former, almost all correspond to a transfer of the latter.

•     Paradox 3 (generational mismatch between the new paradigm of human-machine collaboration and the existing code security engineering):Copy Fail was discovered by Xint Code, a AI assistance system, after scanning Linux crypto/subsystem for about one hour under the condition of “only one operator prompt”. Fragnesia, it was discovered by Zellic’s AI agent audit tool, announcing that “primitive hunting” (primitive hunting) replaced “collapse point search” as the mainstream vulnerability mining paradigm; at the same time, the original code security engineering system, which is based on manual auditing, fuzzy testing, and traditional SAST/DAST, shows structural shortcomings in terms of audit cognitive scale, cross-subsystem semantic reasoning, or patch side effect prediction.

1.3 “Three-body” balance point definition: encryption mechanism (algorithm and protocol), performance (optimization and efficiency), security (defense and verification) of the interaction domain

The Linux kernel presents the following complex three-body looks:

• Encryption mechanism-with AES-GCM (NIST SP 800-38D), IPsec ESP (RFC 4303), HMAC-SHA256, PCBC/FCRYPT and other algorithms and protocols as the core, covering the kernel crypto subsystem, xfrm framework, AF_ALG user mode interface, RxRPC/rxkad and other kernel components.
• Performance (optimization and efficiency) – Kernel hot path engineering optimization strategies represented by zero-copy mechanisms such as splice()/vmsplice()/sendfile()/MSG_SPLICE_PAGES, scatterlist hashing, skb_cow_data omission, skb_try_coalesce merging, and AEAD in-place operations (in-place).
• Security (defense and authentication) – Covers defense-in-depth elements such as kernel access control, namespace isolation, ownership and writability immutability, page cache integrity, module load control, AppArmor/seccomp/SELinux, etc.

The “interaction domain” of the three is concentrated in three engineering sites: first, the ownership semantics of the hash table (scatterlist) – who owns a piece of continuous addressable memory and whether it can be written arbitrarily; Second, the sk_buff frag sharing tag (SKBFL_SHARED_FRAG) – whether the external ownership page is correctly identified; Third, implicit convention of cryptographic primitives for caller buffers-whether algorithms such as authencesn, pcbc (fcrypt), and AES-GCM treat the destination buffer provided by the caller as a writable “draft area”.

1.4 Report discussion scope and terminology agreement

This report is limited to: (1) kernel subsystems and mechanisms touched by four vulnerabilities of Dirty family (Dirty Pipe, Copy Fail, Dirty Frag (with two CVE numbers) and Fragnesia); (2) Code logic, design assumptions and state machine consistency analysis from the perspective of forward engineering; (3) Mapping from the concept of “executive governance” to kernel vulnerability defense. Explicit exclusion: retelling of individual exploit details (see FAQ), broader cybersecurity topics unrelated to the Dirty family of mechanisms, policy statements beyond the technical domain (only briefly mentioned 1.1 and 8.4 necessary).

Terminology convention: -page cache: Linux kernel caches file contents in memory at the granularity of 4KB physical pages, which is fully managed by the kernel without permission check; -scatterlist (hash table): the kernel crypto subsystem describes the chain memory description structure of encrypting/decrypting input and output; -SKBFL_SHARED_FRAG: sk_buff flag bit to indicate that the frag of the skb contains external pages that are not privately owned by the kernel;-In-place operation (in-place): the source and destination of encryption/decryption point to the same memory area; -Attack primitive (primitive): a code path that can be arbitrarily called to produce specific deterministic side effects (such as “4-byte out-of-bounds writing”); -execution entity: A concept proposed by Antiy, which generally refers to the running object that is actually loaded by the operating system and given execution permission, it is the basic governance unit of network security operations.

2. Dirty Family Pedigree: The Technical Deconstruction of Three Connections of Vulnerabilities

2.1 Dirty Pipe (CVE-2022-0847): Pioneered page cache tampering paradigm – zero copy and write-in-place for pipeline subsystems

Dirty Pipe is the paradigm pioneer of the Dirty family. The root cause can be traced back to two kernel changes many years apart: commit 241699cd72a8 in 2016 introduced new pipeline buffer allocation functions copy_page_to_iter_pipe() and push_pipe(), but did not initialize the flags field in the struct pipe_buffer; The commit f6dd975583bd in Linux 5.8 in 2020 introduces PIPE_BUF_FLAG_CAN_MERGE flag bits, used to indicate that the pipe buffer can be merged with newly written data (this flag itself is to improve the write performance of anonymous pipes). Max Kellermann pointed out in his 2022 disclosure that attackers only need to fill and empty a pipeline to keep the flags field of all pipe_buffer PIPE_BUF_FLAG_CAN_MERGE, then introduce the page cache page of the read-only file into the pipeline through splice(), and then write data to the pipeline, the kernel will directly overwrite the page cache page because of the CAN_MERGE flag, thus bypassing the file permission check to tamper with the read-only file, read-only mount and even immutable files.

From a “three-body” perspective, Dirty Pipe already has the core genes of the family: performance optimization (zero-copy splice, anonymous buffer merging) intrudes on ownership semantics, page cache sharing is trusted by default, and the uninitialization of a single flag bit penetrates the entire permission model. The only difference with subsequent family members is that Dirty Pipe does not yet involve encryption-it writes to the page cache directly through the pipe subsystem, where encryption does not act as a channel. This is both a paradigm-setting point and leaves room for subsequent migration of vulnerabilities to cryptographic subsystems.

2.2 Copy Fail (CVE-2026-31431): AI-assisted discovery of encryption bridging vulnerability-AF_ALG in-place decryption and splice() intersection

Copy Fail marks the official entry of the Dirty family into the crypto subsystem. Its vulnerability chain consists of the superposition of three independent and reasonable engineering decisions on the timeline:

• 2011 (commit a5079d084f8b): authencesn template was added to the kernel to support the 64-bit extended serial number of IPsec (ESN, RFC 4303 § 2.2.1). The implementation uses the target buffer provided by the caller as a temporary draft area to rearrange the ESN byte order, and performs the scatterwalk_map_and_copy (tmp 1, dst, assoclen cryptlen, 4,1) in crypto_authenc_esn_decrypt() — that is, writes a 4-byte seqno_lo to the dst offset assoclen cryptlen. The implicit assumption at the time was that only the kernel internal xfrm layer would call the authencesn, and the caller had full control of the target buffer.
• 2015 (commit 104880a6b470 algif_aead.c): authencesn is migrated to the new AEAD interface; At the same time, AF_ALG added AEAD support, exposing the kernel crypto subsystem to unprivileged users through the socket interface.
• 2017 (commit 72548 b093ee3): algif_aead introduce “in-place operation” performance optimization, set req->src and req->dst to the same scatterlist, and link the authentication label page into the output hash table through sg_chain().

There is no obvious security problem in the three decisions alone. However, when the attacker injects the page cache page of the read-only file into the hash table of AF_ALG socket through splice() and then triggers authencesn decryption, the scatterwalk_map_and_copy will “cross” the boundary from the legal output area to enter the linked page cache page, call kmap_local_page() to map it to the kernel writable virtual address, and write 4 bytes of seqno_lo. The value of these 4 bytes is completely controlled by the user in the sendmsg() through AAD(bytes 4-7), forming a deterministic 4-byte arbitrary write primitive.

The repair scheme was submitted by the kernel crypto subsystem maintainer Herbert Xu: commit a664bf3d603d directly rolled back the in-situ optimization in 2017, making algif_aead reuse independent source hash table and destination hash table (TX SGL and RX SGL are separated). Its submission instructions say “it is not good to operate in-place in algif_aead because the source and target come from different mappings”. The discovery process of Copy Fail is more symbolic — Theori researcher Taeyang Lee put forward the “AF_ALG splice” combined attack surface hypothesis based on kernelCTF experience. Xint Code AI platform scans Linux crypto/subsystem for about one hour under the condition of “only one operator prompt” to complete semantic graph traversal across dozens of source files. For the first time, the effectiveness of the collaborative paradigm of “human source insight AI scale and generalization” was verified in engineering. CISA added the vulnerability to the Known Exploits (KEV) directory on May 1, 2026.

The Antiy Research Institute analyzed and interpreted this discovery process in “The New Paradigm of Vulnerability Analysis for Human-AI Collaboration – Copy Fail Discovery Process Analysis”, and extracted three key perceptions: First, the core value of AI-assisted auditing does not lie in “replacing humans to discover vulnerabilities”, instead, it is the rapid scaling of human researchers’ “insight hypotheses” (e. g., “AF_ALG splice’s combined attack surface”) into “planar audits”-the Xint Code platform completes in an hour the cross-subsystem semantic correlation analysis that human auditors take weeks or even months to complete. Second, the vulnerability nature of Copy Fail has typical “emergent” characteristics: authencesn template design in 2011, AF_ALG AEAD interface opening in 2015, in-situ operation optimization in 2017, three independent decisions superimposed on a nine-year timeline, no single commit can be accused of “error”, but the intersection of the three produces a privilege primitive that can be stably used by unprivileged users. Antiy CERT clearly pointed out in the Copy Fail FAQ (above): “The coupling of multiple subsystems is involved… The code audit of a single subsystem is difficult to find such cross-system interaction defects”. Third, Theori team’s security research capability has a profound practical background-it won the third prize of US $1.5 million in the DARPA AI Cyber Challenge(AIxCC) final held on DEFCON 33 in August 2025, and its upstream CTF team MMM (in conjunction with CMU PPP and UBC Maple Bacon) won the DEFCON CTF championship nine times-this shows that the effectiveness of AI-assisted vulnerability mining depends not only on the tool itself, it depends more on the operator’s domain insight and problem modeling capabilities.

Looking at Copy Fail from the perspective of “three-body”, it represents the first complete form of the intersection of encryption mechanism, performance optimization and system security: the encryption subsystem (authencesn) provides the “precise tool” for cross-border writing, and the performance optimization (splice zero-copy AF_ALG in-situ operation) provides the “transmission channel” for introducing page cache pages into the encryption path”, the security mechanism (the shared trust model of the page cache) provides a “storage carrier” that persists after writes”. The coupling of the three makes Copy Fail the first “encryption bridging” vulnerability in the Dirty family-it is the first to prove that a cryptographic subsystem can be weaponized as a precise write primitive for page cache tampering.

2.3 Dirty Frag (CVE-2026-43284, CVE-2026-43500): double primitive chained combination — xfrm-cryptographic path coupling of ESP and RxRPC

Dirty Frag consists of two independent vulnerability chains, CVE-2026-43284 (xfrm-ESP Page-Cache Write) and CVE-2026-43500 (RxRPC Page-Cache Write), which were publicly disclosed by Hyunwoo Kim on May 7, 2026 due to the early rupture of the embargo.

xfrm-ESP Page-Cache Write (CVE-2026-43284): The root cause of this vulnerability can be traced back to the commit cac2661c53f3 (“esp4: Avoid skb_cow_data whenever possible”) in 2017 and the corresponding esp6 version commit 03 e2a30f6a27. Its performance optimization goal is: when the sk_buff is not cloned and has no frag_list, the esp_input() skips the skb_cow_data() and directly performs in-situ decryption on frag. The underlying premise of this optimization is that frag is privately held by the kernel. However, when the attacker directly attaches the page cache page in the pipeline to the UDP/ESP-in-UDP sk_buff through MSG_SPLICE_PAGES (commit 7da0dde68486 and 6 d8192bd69bb) or splice(), the IPv4/IPv6 datagram splicing path does not set the SKBFL_SHARED_FRAG flag like TCP’s skb_splice_from_iter(), making a nonlinear skb that should be regarded as “containing external ownership fragments” look exactly the same as an ordinary uncloned nonlinear skb. The esp_input thus enters the no-COW fast path and executes crypto_authenc_esn_decrypt() directly on frag-this is exactly the same as Copy Fail’s sink, and the attacker can obtain 4 bytes of arbitrary write primitives at the specified page cache offset by controlling the copy. Red Hat gave the CVE a CVSS 3.1 score of 8.8 HIGH (based on the kernel.org CNA assessment) and a Canonical score of 7.8 HIGH.

RxRPC Page-Cache Write (CVE-2026-43500): This vulnerability is located at the rxkad_verify_packet_1 of net/rxrpc/rxkad.c () and has been introduced since June 2023 by commit 2dc334f1a63a. When the RXKAD security layer validates the packet, the kernel performs an in-place pcbc(fcrypt) monolithic decryption of the first 8 bytes of the RxRPC payload in the skb. fcrypt is a 56-bit key block cipher left over from the RxRPC/AFS protocol. The key can be add_key by non-privileged users (“rxrpc”,…) Free registration. In the user state, the attacker violently searches for the key k at a rate of about 18 million times per second (I.e. “fcrypt runs ~ 18 million keys/second, resolving in milliseconds to ~ 1 second per chunk”, TheCybrDef the measured data of Hyunwoo Kim in V4bel/dirtyfrag write-up), so that the fcrypt_decrypt (C, K) is equal to the target plaintext p, this “implants” any 8-byte content in the page cache (typically by changing the root line password field of/etc/passwd to empty and logging in without a password using the ok option of pam_unix.so).

The reason why the two vulnerabilities are “chain complementary” stems from the opposite coverage blind area: the xfrm-ESP path needs to create a user namespace (some Ubuntu is intercepted by AppArmor default), but the esp module is loaded by default in almost all distributions; RxRPC path does not need namespace at all, but rxrpc.ko is only loaded by default in a few distributions such as Ubuntu. The combination is stable on all major Linux distributions. Upstream xfrm-ESP repair is submitted by Kuan-Ting Chen and Steffen Klassert (commit f4c50a4034e6). The core idea is to explicitly set the SKBFL_SHARED_FRAG flag for IPv4/IPv6 datagram splice frag and make ESP input fall back to skb_cow_data() when the flag exists.

2.4 Fragnesia (CVE-2026-46300): Patch derivation vulnerability – state machine fracture to fix patch activation ancient defects

Fragnesia was disclosed by William Bowling (V12 Security/Zellic) on May 13, 2026 only 5 days after the Dirty Frag fix, and is the most alarming “patch-derived vulnerability” in this family “. Its root is not in the esp4/esp6/rxrpc module itself, but in the kernel core socket buffer code skb_try_coalesce(): when the GRO (Generic Receive Offload) path merges multiple sk_buff, this function does not propagate the SKBFL_SHARED_FRAG flag from the merged skb to the merged skb. The result is that even if the Dirty Frag patch has correctly set the SKBFL_SHARED_FRAG flag for the IPv4/IPv6 datagram splice frag, the flag may be lost during subsequent skb merges.

The sharper dialectical relationship is that the Fragnesia attack path is exactly what the Dirty Frag patch “introduced” — the Dirty Frag fix causes ESP input to fall back to skb_cow_data when the SKBFL_SHARED_FRAG exists, but if the flag is skb_try_coalesce dropped, the fall back will not occur, leaving an updated attack path instead. Hyunwoo Kim thus explicitly described the Fragnesia as a dormant flaw “accidentally activated by the Dirty Frag patch. Specifically, the Fragnesia attacker obtains the CAP_NET_ADMIN in the isolated namespace through the unshare(CLONE_NEWUSER | CLONE_NEWNET), and installs a ESP-in-TCP transmission mode SA constructed with a known AES-128-GCM key by means of the NETLINK_XFRM. After the page cache page to be written is put into the TCP receiving queue through splice(), the socket is switched to the espintcp ULP mode, and the kernel performs in-situ AES-GCM decryption on the page cache page in the queue. An attacker constructs a 256 key stream lookup table by AF_ALG in advance, and can generate a definite one-byte write after XOR the AES-GCM key stream by controlling IV nonce-a step that completely transforms “encryption” from a passive data carrier into an active attack tool.

Fix commit f84eca581739 allow skb_try_coalesce() to correctly propagate SKBFL_SHARED_FRAG flags, along with propagation fixes in pskb_copy(), and a set of associated patches including rxrpc DATA/RESPONSE package unsharing, rxkad alignment, potential UAF fixes. It is worth noting that the V12 team subsequently disclosed on May 15, 2026 that the skb_segment() only spread the SKBFL_SHARED_FRAG sign of head skb and ignored frag_list members when constructing GSO segments-this side road has not been completely repaired, which once again confirms the “layer by layer” of state machine consistency problems “.

2.5 Genealogy evolution: from single-point vulnerabilities to chain combinations to patch-derived generational transitions.

Putting the four vulnerabilities into the same coordinate system, a clear generational transition is visible:

Intergenerational	Delegate Vulnerability	Encrypted coupling	Form	Method of Discovery
First generation	Dirty Pipe (2022)	None	Single point uninitialized flag bit	Tracing to the Source of Occasional Collapse
Second generation	Copy Fail (2026-04)	AF_ALG authencesn	Emergent primitives across three subsystems	AI-assisted primitive hunting
Third generation	Dirty Frag (2026-05)	xfrm-ESP RxRPC/rxkad	chain complementary double primitive	Human Researcher Pattern Recognition
Fourth generation	Fragnesia (2026-05)	XFRM ESP-in-TCP AES-GCM	State machine fracture activated by patch side effect	AI Agent Auditing

The rules can be summarized as follows: first, encryption coupling goes from scratch to initiative-from Dirty Pipe not involving encryption at all, to Copy Fail/Dirty Frag completing writing with encryption sink but encryption itself is only a “carrier”, to Fragnesia directly generating attack effects by AES-GCM the algorithmic semantics of key stream XOR. Second, the granularity of primitives is from coarse to fine-from Dirty Pipe’s “overwrite in byte order” to Copy Fail’s “write in any 4 bytes” to Fragnesia’s “write in any single byte”. Third, discovery is moving from people-based to AI-based-AI-assisted audits are reshaping the discovery cost curve for such logical vulnerabilities.

2.6 Common root causes: the “three-body” intersection of encryption operation in situ, zero-copy performance optimization, and page cache sharing.

Abstracting the root causes of the four vulnerabilities to the highest level, the commonality is rooted in the structural mismatch created by the intersection of the three bodies:

1. Page cache shareability – Linux is always designed to treat the page cache as a global resource that is privately writable by the kernel and transparently shared by all processes;
2. Zero-copy writable references-mechanisms such as splice/sendfile/MSG_SPLICE_PAGES retain the “source (provenance)” information of the page for performance, and pass the page cache page to other subsystems in the form of references;
3. Write-in-place of cryptographic primitive – A side-effect write to the caller buffer (authencesn draft, AES-GCM keystream XOR, pcbc (fcrypt) block overwrite) was performed before the authentication failed.

The combination of any two of the three is not enough to trigger the vulnerability-only when all three work together can a deterministic write primitive of “no race, no kernel panic, no offset, no retry” be formed. This is precisely the engineering root of the Dirty family vulnerability “Emergence (emergent)” outbreak.

3. The Performance Dimension: The Fracture of Optimization Logic and Safety Assumptions

3.1 Performance bottleneck of core hot path: efficiency pressure of network stack, encryption path, memory management

The Linux kernel has long assumed the dual roles of “general-purpose commercial OS” and “high-performance infrastructure OS. On the three hot paths of network stack, encryption path and memory management, the performance pressure is extremely concentrated: the network stack needs to process millions of data packets per second, and each copy means thousands of CPU cycles and cache pollution; The encryption path should not only support throughput-intensive applications such as IPsec/TLS, but also meet storage encryption requirements such as dm-crypt/fscrypt. Memory management allocates, releases and recycles 4KB physical pages very frequently, any additional page copies will translate into a system-level performance penalty. This pressure has led to a long-standing “performance-first” engineering bias in the kernel development culture-all omissible copies, all mergeable buffers, and all shareable references constitute “vested gains” for developers “.

3.2 Design Philosophy and Memory Semantic Trap of  Zero-copy Mechanism (splice())

The splice() system call was introduced by Jens Axboe on Linux 2.6.16(2006). Jonathan Corbet documented the key statement of Linus’s Torvalds in the LWN.net February 2023 article “Rethinking splice()”: the sharing of buffers “is what splice is all about”. splice() achieves zero copy by letting the pipeline pipe_buffer directly reference the page cache, avoiding data replication between the user state and the kernel state, as well as data replication within the kernel. Another article by LWN.net (Articles/178725) pointed out that “zero-copy really means zero CPU copies”-the core value of zero-copy mechanism lies in avoiding CPU from performing high-cost data copy operations.

However, this sharing brings a kind of memory semantic trap that is difficult to identify with the naked eye: the ownership (ownership) and writability (writability) of pages injected into downstream subsystems (pipe, socket, crypto hash table, sk_buff frag) through splice() are not passed along. For the receiving side, it is just a piece of “addressable physical memory” and does not contain meta-information about “who owns this piece of memory and whether it is allowed to be written. All of the vulnerabilities of the Dirty family are essentially based on this “loss of semantic information. The “surprising” behavior that Samba developer Stefan encountered Metzmacher using splice in LWN’s February 2023 article has partially foretold such problems-but the overall perception of the problem in the kernel community remains at the level of “individual user considerations.

3.3 Triple Performance Gain and Single Security Cost in-Place Operations

In-place in the encryption path brings three performance benefits to the kernel: (1) omitting input-to-output memory copies (typically saving one full buffer copy); (2) reducing the number of scatterlist descriptors (src and dst merging); and (3) improving cache locality (same physical page reads and writes remain hot in L1/L2). But the price is only one: the source buffer is secure if and only if it is privately owned by the kernel before and after encryption. Any caller that breaks this premise introduces risk.

The Dirty family proves that this premise is broken simultaneously on multiple independent code paths:

• algif_aead open the in-place operation capability to non-privileged users through AF_ALG socket (Copy Fail);
• xfrm-ESP extend the in-place operation to the sk_buff path (Dirty Frag) by “skipping the skb_cow_data and operating directly on frag;
• rxkad_verify_packet_1 Dirty Frag by doing a single pcbc(fcrypt) on the RxRPC payload in frag;
• espintcp ULP does not switch modes until the socket has been injected into the splice page (Fragnesia).

The optimization decisions of the four paths are unrelated to each other, but their failure patterns are strictly isomorphic-a sign of an emergent vulnerability.

3.4 Avoid skb_cow_data and skb_try_coalesce(): The “Gain Illusion” and “Risk Dark Matter” of Optimized Code”

Two more typical examples are skb_cow_data omission and skb_try_coalesce(). The role of the skb_cow_data is as follows: “Make sure that the data buffers attached to a socket buffer are writable. If they are not, private copies are made of the data buffers and the socket buffer is set to use these instead”-it is a key line of defense of ownership within the sk_buff system. The optimization goal of the 2017 commit cac2661c53f3 (“esp4: Avoid skb_cow_data whenever possible”) is completely reasonable-skipping COW for uncloned and frag_list skb can significantly reduce the memory pressure of IPsec data path-but it misses the implicit condition that “not setting SKBFL_SHARED_FRAG does not mean that there is really no shared frag. This “seemingly strict but not all listed” state determination is the common “risk dark matter” in performance optimization code “.

The role of skb_try_coalesce() is more hidden. As a merge optimization of GRO and TCP receiving side, its official semantics is “try to merge skb to prior one”-it merges multiple sk_buff frags into the previous sk_buff to reduce allocation. However, the merger process missed the spread of the SKBFL_SHARED_FRAG logo-this is the root cause of the Fragnesia. In terms of engineering quantities, the deletion is “invisible”-it does not cause any data errors, does not affect functional correctness, does not cause any crashes, and is simply a silent metadata propagation failure. Because of this missing zero cost, it went undetected in years of code reviews.

3.5 Performance-Security Zero-Sum Game: Why Optimizing Code Is the Motive Force of Vulnerabilities”

By combining the above clues, the relationship between performance optimization and security presents a clear “zero-sum” feature on the core thermal path:

1. Copying is one of the core mechanisms of security-each copy establishes ownership boundaries and strips away the “provenance” of the source “;
2. Zero copy is one of the core mechanisms of performance-each copy omission opens the ownership boundary;
3. Optimized code defaults to “ideal assumptions”-developers tend to assume that “good” input is passed upstream;
4. Attackers take the initiative to create “bad input”-splice to AF_ALG, unshare to xfrm-ESP, CLONE_NEWUSER to ESP-in-TCP, are deliberately constructed by the attacker “bad entrance”.

Therefore, optimized code is objectively the “vulnerability motive force” – it continues to release new attack surfaces on the hot path. This zero-sum nature is not the result of “engineer-level deficiencies”, but rather a natural structural destructive tension between performance goals and security goals at the core architecture level.

4. Cryptographic Mechanism Dimension: The Gap Between Algorithm Semantics and System Semantics

4.1 “Memory Security Blind Zone” of the Encryption Mechanism Standard: Assumptions of Algorithm Correctness for NIST SP 800-38D, RFC 4303

NIST SP 800-38D(Morris Dworkin, 2007) and RFC 4303(Stephen Kent, December 2005) are the two core standards involved in this family, and their expression accuracy is extremely high-they specify AES-GCM initialization vector structure, uniqueness constraint, authentication label length, IPsec ESP packet format, ESN serial number management, anti-replay window, etc. NIST officially announced on March 5, 2024 that SP 800-38D will be revised to include “remove support for authentication tags whose lengths are less than 96 bits, clarify that the construction of initialization vectors (IVs) for GCM in the Transport Layer Security (TLS) 1.3 protocol is approved.

However, they share a common “memory security blind spot”-they discuss algorithmic/protocol correctness and do not constrain the caller’s memory ownership, buffer lifecycle, or kernel semantics of in-place operations. This blind spot is sound in engineering-the scope of applied cryptography (in the sense of implementing cryptographic protocols) standards should not have extended to the memory model of the operating system. However, when the algorithm implementation is embedded in a kernel environment with shared page cache, zero-copy reference and in-place operation, the “silence” of the standard layer is transformed into the “disorder” of the implementation layer “. The authencesn ESN rearrangement “draft write” strictly conforms to RFC 4303 § 2.2.1 for the processing of 64-bit extended sequence numbers. The AES-GCM keystream XOR lattice conforms to the ciphertext construction definition in section 6 of NIST SP 800-38D-but both assume that the target buffer provided by the caller is “all private to the caller”. This implicit assumption has never appeared in any standard, nor in any API annotation.

4.2 Hub Position of Encryption Subsystem: Cross-domain Data Stream Aggregation and Attack Surface Enrichment

The Linux kernel crypto subsystem has a “hub” status in structure: high-strength data flows such as dm-crypt/fscrypt (storage), kTLS (network), IPsec/xfrm (VPN), RxRPC/AFS (distributed file system), AF_ALG (user-state encryption API), and modules signature authentication (load protection) are all aggregated in the same set of core templates (authenc, authencesn, gcm, ccm, pcbc (fcrypt), and cbc (aes) of the crypto) of the crypto API. This pivotal status means that the boundary assumption of any crypto primitive is wrong and will be triggered in different forms in multiple upstream subsystems.

The Dirty family provides a typical case of “hub amplification”: the authencesn 4 bytes out of bounds are written on the algif_aead path to form Copy Fail, one of the Dirty Frag is formed on the xfrm-ESP path, and the AES-GCM key stream XOR combination is formed on the espintcp path to form Fragnesia deeper utilization chain.

Antiy CERT analyzed the key position of the encryption subsystem in Copy Fail FAQ (below): the pivotal position of Crypto API creates a “double-edged sword” effect-unified encryption service avoids repeated development of subsystems, and the scatter list efficiently supports IPsec’s processing of paged skb, however, the intersection of the three data streams (file system → encryption, network stack → encryption, user space → encryption) in the encryption subsystem greatly enriches the attack surface. Copy Fail utilizes file system → encryption path, Dirty Frag ESP variant utilizes network stack → encryption path, Dirty Frag RxRPC variant utilizes local socket → encryption path. Hub status means that breaking any access point can gain the ability to inject data into other domains. Antiy CERT pointed out that this hub amplification effect is the key feature that distinguishes the Dirty family from traditional kernel LPE vulnerabilities-traditional vulnerabilities are usually limited to a single subsystem, while the attack path of the Dirty family naturally has the ability of “cross-domain jump”, and the boundary assumption error of a single crypto primitive can be triggered in different forms in multiple upstream subsystems.

4.3 The paradox of “audit masking” and “controllable use” of encryption: the suppression of security review by the obfuscation mechanism and the precise control of the attack side

The essence of encryption is to map “the semantics of plaintext domain” to “the chaos of ciphertext domain”. This confusion causes audit cover on the defense side-the encryption process will actively destroy the semantic interpretability of the data, and the traditional taint analysis and symbol execution are difficult to cross both ends of the encryption primitive; On the attack side, because the key and algorithm can be controlled by the attacker (through ALG_SET_KEY in Copy Fail, through add_key (“rxrpc”,…) in Dirty Frag/RxRPC, and through known keys installed by NETLINK_XFRM SA in Fragnesia), cryptographic algorithms are instead completely deterministic and predictable to an attacker: given an input and a key, the output can be derived exactly. Thus, “4-byte/1-byte definite write to page cache” can be stably constructed as an attack primitive.

This asymmetry constitutes the core paradox of the “encryption-security negative sum”: increased defense complexity does not necessarily improve security, but may provide attackers with more stable and precise exploitation semantics. The Dirty family is not an example, it reveals the structural weakness of the Linux kernel encryption subsystem in the attack and defense game-the existence of encryption within the system itself, expanding the attack surface rather than shrinking.

4.4 From Passive Carriers to Active Tools: Risk Introduction AES-GCM Keystream XOR

The engineering value of the Fragnesia is to elevate encryption from a “passive data carrier” to an “active attack tool”. In Copy Fail and Dirty Frag, the encryption path simply “carries” the attacker’s write to the target offset (authencesn writes 4 bytes to dst[assoclen cryptlen], pcbc (fcrypt) writes 8 bytes to the frag start); the attacker controls the write value itself or the computable key. However, in Fragnesia, the attacker actually makes the AES-GCM algorithm actively produce the writing effect-AES-GCM decryption performs XOR between the ciphertext and the key stream, while the attacker makes each byte of the key stream predictable and selectable by controlling the IV nonce and the key stream lookup table under a known key, thus turning the core step of the algorithm “key stream XOR” into “accurate single byte writing to the page cache”.

This shift marks the ultimate in the Dirty family’s “cryptographic coupling”: the encryption mechanism has become not only a link in the chain of vulnerabilities, but almost an execution engine for them.

4.5 “Botany” of Legacy Cryptographic Mechanisms: Compatibility of RxRPC/fcrypt Debt and Pure Risk Attributes

fcrypt is the 56-bit key block cipher that the RxRPC/rxkad security layer (kerberos 4 equivalent protocol, security index 2) relies on, derived from the design of AFS(Andrew File System) in the 1980 s. The Linux kernel net/rxrpc/Kconfig shows the explicit select CRYPTO_PCBC and select CRYPTO_FCRYPT in the RXKAD configuration options. From the perspective of pure cryptography, it has long been completely replaced by modern standards (AES, ChaCha20-Poly1305), and 56-bit keys can be exhausted on ordinary desktop CPU-according to the measured speed of 18 Mops/s by V4bel write-up, a single key search is in the range of milliseconds to about 1 second. However, due to the compatibility requirements of legacy ecosystems such as OpenAFS and kAFS for rxkad, the fcrypt and PCBC modes remain in net/rxrpc and crypto/fcrypt.c.

This reservation has its engineering justification-the open source community is extremely sensitive to compatibility liabilities that “destroy the existing ecology”-but its security attributes have undergone a qualitative change: from a “usable but weak” compliance component to a “pure risk” negative code legacy. fcrypt no longer provides meaningful confidentiality protection (attackers can easily brute out keys), but still bears the side effect of “performing in-place decryption on frag”, which is precisely exploited by Dirty Frag’s RxRPC variant. The legacy encryption mechanism thus becomes a “zombie liability” for the Dirty family-its cryptographic value is dead, but its code side effects are still alive.

4.6 Encryption mechanisms – the positive-sum illusion of performance: Misalignment of hardware offloading versus software paths

Cryptographic mechanisms and performance are superficially “positive-sum” – AES-NI, CLMUL(PCLMULQDQ) and other instruction sets bring AES-GCM close to “zero-cost encryption”. But this sum only exists at the “algorithm layer”. At the “system layer”, the security cost of the optimization of the encryption path (operation in place, zero copy, skip COW) is not offset by any hardware instructions. When engineering practice is misled by the cognition that “hardware encryption is very cheap, so it can be widely used”, developers often underestimate the increase of attack surface caused by the exposure of encryption portal to unprivileged user state — the existence of AF_ALG is originally intended to let OpenSSL and other user state libraries use kernel hardware encryption, but few applications actually widely use AF_ALG (OpenSSL afalg engine, cryptsetup, kcapi-tools), however, it provides a complete key stream lookup table capability for Copy Fail and early Fragnesia attack paths.

Encryption-the sum of performance is therefore an illusion-its apparent “win-win” is implicitly offset by the “additional attack surface of the software path.

5. Code Security Engineering Dimension: Structural Shortcomings of Open Source Community Security Operation Capability

5.1 The “Security back” in forward design: the performance-first tradition of kernel development culture

The development culture of the Linux kernel has long been a “right, fast, safe” priority-a culture that has been socially shaped by Linus Torvalds and core maintainers for more than 30 years. The discussion patterns of LKML and netdev mailing lists are equally strongly inclined to “code is argument, performance data is truth”. However, the model’s acceptance of security side effects is relatively weak: when a patch brings a 5% throughput increase, the community will not require it to submit “regression proof of security invariance for all adjacent code paths” at the same time “. This culture is not unique to Linux, but its scale-tens of millions of lines of kernel code, thousands of subs, hundreds of subsystems-makes the cumulative effect of each “security behind” far more than other open source projects.

All the root causes of Dirty family commit(241699 cd72a8, f6dd975583bd, 72548 b093ee3, cac2661c53f3, 03 e2a30f6a27, 2 dc334f1a63a, 7 da0dde68486, 6 d8192bd69bb) have undergone strict Reviewer review and community discussion at the time of integration, but the focus of the discussion is almost entirely on functional correctness and performance data, and none of the integrated discussions clearly questioned “whether the optimization has destroyed the ownership invariance of upstream and downstream subsystems”.

The Linux kernel is known for its modularity, with clear boundaries for interfaces (API/Hook/Notifier Chain) between subsystems. But modularity only addresses the functional contract-“I call skb_cow_data and you give me writable sk_buff”-and does not address the semantic contract-“whether the frag in the sk_buff I pass to you has real ownership”. Copy Fail exposes the semantic break in the call chain of splice → AF_ALG → algif_aead → authencesn: each module is audited separately, but the semantics are lost at the boundary.

5.2 The fuzzy zone of cross-subsystem security contracts: clear module boundaries but semantic fracture

InfoQ’s “Copy Fail and Dirty Frag: Linux Page-Cache Exploits Target Every Major Distribution” of May 2026 quotes Hyunwoo Kim’s discussion on the relationship between the two: “xfrm-ESP Page-Cache Write provides a powerful arbitrary 4-byte STORE primitive like Copy Fail, and is included on most distributions, but it requires the privilege to create a namespace. RxRPC Page-Cache Write does not require the privilege to create a namespace, but the rxrpc.ko module itself is not included in most distributions” — One sink, two sources. This “multi-source co-sink” is a typical exposure of modular design in the absence of cross-subsystem security contracts.

5.3 The Intergenerational Lag of Auditing Paradigm: The Cognitive Gap from “Crash Point Discovery” to “Primus Hunting”

Traditional kernel vulnerability mining has long taken “crash point” as its core goal: the main detection mechanisms of tools such as Syzkaller, AFL, KASAN, and KMSAN are all to capture errors that can explicitly trigger exceptions such as illegal memory accesses, UAF, and OOB. From the discovery of the crash to the realization of “controlled crash”, in the early inspiration to the Fuzzing of the process, are regarded as the basic paradigm from the discovery of vulnerabilities to the formation of PoC. The Dirty family poses a systematic challenge to this paradigm-none of the four vulnerabilities will cause kernel crash: HMAC verification failure in Copy Fail only returns EBADMSG, AEAD authentication failure in Dirty Frag only shows ordinary error codes, and AES-GCM tag verification failure in Fragnesia is also only a failure return. However, the 4-byte or 1-byte write side effect to the page cache is completed long before the error is reported. It is difficult for the traditional fuzzing framework to obtain effective feedback signals from such vulnerabilities.

Theori’s “primitive hunting” paradigm is replacing the collapse point paradigm. Researchers (people) put forward the assumption of “zero copy page cache of encrypted interface” based on the insight ability established by long-term deep cultivation of Linux kernel attack and defense. Based on the computing power construction of its thousand-card platform, the AI platform (machine) traverses semantic graphs across files and subsystems in millions of lines of code, locate “On which paths a page cache page introduced by splice may enter a writable scatterlist”. A scan of Linux crypto/subsystem for about one hour can be found with “one operator prompt. -Demonstrated the discovery efficiency of the new paradigm. This is what Antiy pointed out in “Discovery of Copy Fail Vulnerability Shows New Human-Computer Division of Labor”. People focus on “asking the right questions” and are AI responsible for “asking all relevant questions”.

5.4 The ‘sufficiency illusion’ of repair responses: systematic deficiencies in patch verification coverage

The very existence of the Fragnesia is the most severe test of the adequacy of the patch. The fix for Dirty Frag-setting a SKBFL_SHARED_FRAG for IPv4/IPv6 datagram splice frag and having ESP input fall back to COW if the flag is present-is a logical and targeted fix. Five days later, however, the Fragnesia bypassed the patch by missing skb_try_coalesce flag propagation-indicating that the community did not systematically verify the “global consistency of the flag state machine.

Furthermore, on May 15, 2026, after Fragnesia fixing the commit f84eca581739, the V12 team disclosed a similar problem of skb_segment() (only the SKBFL_SHARED_FRAG of head skb was transmitted during GSO segmentation, ignoring frag_list members)-a cascade effect of “patching and patching.

The root of this “sufficiency illusion” is that patch verification only covers the code path directly modified by the patch, not all paths related to the state variable-that is, the open source community lacks a globally consistent verification infrastructure on key state variables such as flags, ownership pointers, and reference counts.

5.5 “Audit Immunity” of Performance Hot Path: Security Blind Zone and Long-term Dormancy Defect of High Frequency Code

Splice, skb_try_coalesce, authencesn and other codes have been in the high-frequency hot path of the Linux kernel for a long time, and are widely involved in zero-copy IO, page cache reuse and encrypted data processing. However, these paths have the strongest “audit immunity”-their code is considered “proven in the field” because of high frequency operation, the logical complexity is considered to be a high risk of modification, and security hardening is often seen as potentially disruptive to throughput and latency performance due to performance sensitivity. The nine-year latency of Copy Fail and Dirty Frag in the relevant path is the direct cost of the exemption mechanism.

5.6 Structural Shortcomings of Open Source Community Security Operation Capability: From Individual Heroism to systematic Audit

Connecting the above five points, we can see the structural shortcomings of the safe operation of the open source community:

• Mining side: highly dependent on personal heroism (Max Kellermann, Taeyang Lee, Hyunwoo Kim, William Bowling), lack of systematic scanning infrastructure for emerging vulnerabilities;
• Audit side: mainly based on fuzzy testing such as syzbot, lack of cross-subsystem semantic invariance verification;
• Response side: mainly single-point patches, lack of state machine consistency analysis of patch side effects;
• Disclosure side: The oss-security/linux-distros embargo process has been compromised by a third party on Dirty Frag, shaking the “trust premise” of coordinated disclosure. HackerOne’s Internet Bug Bounty project announced on March 27, 2026 that it would suspend the acceptance of new vulnerability submissions (Dark Reading 2026-04 quoted HackerOne public statement: “Effective March 27, the program paused accepting new vulnerability submissions because of what HackerOne described as a worsening imbalance between vulnerability discoveries and the ability for open source maintainers to remediate them”), which is the most direct proof of this systematic imbalance.

This is not to deny the overall effectiveness of the open source community-the upstream response to fixing complex vulnerabilities is still positive and trying its best (Copy Fail took only 9 days from Theori’s internal nuclear safety team submitted on March 23 to April 1 to patch integration into the main line, and disclosed and exposed on April 29, which also reserved a one-month time period for user updates). However, the Dirty family has proved three times in a row, relying solely on the “fast” of emergency repair cannot compensate for the “leakage” of design verification, and there must also be scene-side collaboration with third-party security capabilities.

6. A Dialectical Analysis of the Relationship between the Three: Dilemma and Balance

6.1 the Inevability of the “Three-Body” Dilemma: Performance-Secure Zero-sum, Encryption Mechanism-Secure Negative-sum, Encryption Mechanism – Performance Positive-sum Illusion

Integrating the foregoing analysis, the relationship can be summarized as follows:

• Performance consumption↔System security: (necessarily) zero-sum-every zero-copy/in-place optimization gives up ownership segregation;
• encryption mechanism↔System security: (partial) negative sum-the controllable hub status of the audit masking attack end of encryption, so that encryption objectively provides precision capability for the attack;
• Encryption mechanism↔Performance: (illusion) positive and-algorithmic acceleration of hardware instructions is difficult to offset the attack surface introduced by “exposure to unprivileged user states” on the software path.

The three pairs of relationships reinforce each other and constitute a “three-body dilemma”. This dilemma is not the result of a specific design error, but the structural tension that the Linux kernel is bound to encounter as a “general high-performance security” complex target coexistence system.

6.2 Emergent vulnerabilities “three-body” coupling: Dirty family as the emergence of “optimized encryption”

Each vulnerability in the Dirty family is hardly attributable to a single commit, a single developer, or a single subsystem (except for one implementer and one introducer of the Copy Fail mechanism)-they are more of an emergent vulnerability (emergent vulnerability): three or more independent and reasonable engineering decisions superimposed on a multi-year timeline, resulting in non-linear security consequences. Antiy CERT has pointed out in the Copy Fail FAQ (above) that “the coupling of multiple subsystems is involved… the code audit of a single subsystem is difficult to find such cross-system interaction defects”, which is fully consistent with the arguments in this section.

Antiy Research Institute refers to the existing data, summed up the emergence of vulnerabilities have three engineering properties: (1) the root cause of the non-local-repair any root cause commit can block the vulnerability, but look at any root cause commit are “no wrong”. Any of the root causes of Copy Fail (authencesn template design, open AF_ALG interface, in-place operation optimization) are beyond reproach in independent review, but the combination of the three produces page cache-level arbitrary write capability. (2) Low observability of latency-routine fuzzing, CI, Reviewer review will not trigger an alarm. None of the four Dirty family vulnerabilities will crash the kernel. Authentication failure only returns an error code, but the write side effect has been completed. This “silent utilization” feature makes traditional crash-oriented audit tools completely ineffective. (3) The side effects of the repair are difficult to predict-a single point of repair may activate other root causes. Fragnesia is the classic case: Dirty Frag’s repair patch is logically tight, but it accidentally activates a 13-year-old flag propagation flaw in skb_try_coalesce(). In “Fragment Amnesia”-How the Dirty Frag Patch gave rise to Fragnesia vulnerabilities “, Antiy traced the complete causal chain of the patch’s side effects in detail.

Emergent vulnerabilities have the following three engineering properties: (1) non-locality of root causes-fixing any root cause commit can block the vulnerability, but looking at any root cause commit alone is “error-free”; (2) Low observability of latency-routine fuzzing, CI and Reviewer review will not trigger alarms; (3) Unpredictable side effects of repair-single point repair may activate other root causes (Fragnesia is typical).

6.3 From “Impossible Triangle” to “Conditional Coexistence”: A Technical Path to Break the Zero-sum Game

Is this “three-body” dilemma destined to be difficult to achieve balance? The answer at the engineering level is “conditional coexistence”. Conditions include:

• Explicit ownership semantics-the flag bit mechanism represented by SKBFL_SHARED_FRAG is extended to other description structures such as scatterlist (such as imaginary CRYPTO_REQ_MAY_SHARE), pipe_buffer, etc;
• Document the memory contract of the encryption API-explicitly declare the “draft write” behavior of templates such as authencesn, and prohibit callers from linking non-writable areas;
• Zero-copy path “Provenance” propagation invariance verification-any zero-copy reference must carry provenance meta-information;
• State machine global consistency check for patch side effects-any patch that modifies SKBFL_SHARED_FRAG behavior must be regression-verified at all propagation points, such as skb_try_coalesce, skb_segment, pskb_copy, etc.

6.4 Global consistency verification of state machines: as a technical intermediary for “three-body” balance

State machine global consistency verification (State Machine Global Consistency Verification) plays the role of technical intermediary in the “three-body” balance-it does not require the abandonment of performance optimization, nor does it require changes in encryption standards, but requires that each cross-subsystem state variable remains semantically unchanged on all propagation paths. For the Dirty family, key state variables include:

• SKBFL_SHARED_FRAG(sk_buff shared frag tag);
• pipe_buffer.flags (especially PIPE_BUF_FLAG_CAN_MERGE);
• scatterlist the ownership attribute of. page (implicit, no explicit flag);
• The sequence number directionality of xfrm_state.replay_esh.

Formal methods (such as TLA, Coq, Iris) are difficult to be fully popularized in the Linux kernel, but bounded model checking (bounded model checking) can be done on the propagation path of key state variables, which is the engineering basis for the 6.5-section human-machine collaborative rebalancing.

6.5 Rebalancing of human-computer collaboration: AI-assisted state machine verification to deal with AI-assisted vulnerability mining

One of the core manifestations of the attack-defense imbalance is that Theori/Xint Code platform can rely on large-scale computing power clusters to complete a comprehensive semantic graph traversal for the Linux crypto subsystem in about one hour with only one operator prompt. The speed of this analysis has far exceeded the auditable limits of human safety researchers. In The New Paradigm of Vulnerability Analysis for Human-AI Collaboration, Antiy makes it clear that the only viable path to counter this paradigm shift is not to “intercept AI with rules”, but to “resist AI-assisted mining with AI-assisted verification”-specifically to the Dirty family, namely:

• AI-assisted audit primitive-continuous scanning of the Linux full tree in the mode of “zero-copy reference in-place write page cache source;
• AI-assisted state machine consistency verification-build global data flow diagrams for key state variables to automatically discover propagation misses;
• AI-Assisted Patch Side Effect Prediction-Predict the state effect on adjacent code paths before the patch is incorporated.

The key to this rebalancing is not “AI substitutes”, but rather the scaling of human-sourced insights (such as the attack surface hypothesis of “AF_ALG splice”) into planar audits.

7. Realization Path of “Three-body” Balance: Security Architecture Reconstruction

7.1 Memory Security Contract for the Cryptographic API: CRYPTO_REQ_MAY_SHARE and Explicit Authentication Interfaces

The Linux kernel crypto API currently lacks explicit flags for writability, ownership, and sharing of caller memory. We recommend introducing a CRYPTO_REQ_MAY_SHARE-like request flag to indicate that the aead_request’s src/dst may contain external ownership pages; the template implementation (if authencesn) must switch to out-of-place mode or actively reject when the flag is present. It is accompanied by scatterlist ownership meta information: each scatterlist element should carry enumerated ownership attributes such as SG_OWNED_BY_KERNEL, SG_BACKED_BY_PAGE_CACHE, and SG_FROM_USER_SPLICE.

7.2 Architecture-level transformation of page cache management: shared page tagging, COW mandatory, merge path reconstruction

The page cache is currently “unconditionally writable” for all write paths “. It is recommended to introduce a write path whitelist mechanism: only VFS write paths, file system-specific write paths, and explicit mmap MAP_SHARED write paths can write page cache pages; other paths (including crypto in-place, scatterwalk_map_and_copy, etc.) must be COW first. This transformation requires a skb_cow_data semantic upgrade-from “whether the sk_buff itself is writable” to “whether all frag in the sk_buff are private to the kernel”. skb_try_coalesce, skb_segment, pskb_copy, etc. merge/segment paths must treat SKBFL_SHARED_FRAG as “propagation invariants”.

7.3 Cross-subsystem security contracts: Explicit origin semantics of buffers and verification of propagation invariance

Mechanisms such as splice/sendfile/MSG_SPLICE_PAGES should carry an “origin tag” to identify the origin of the page from the page cache, anonymous memory, device DMA area, etc. Any API(pipe_buffer, sk_buff frag, scatterlist) that passes buffers across subsystems must pass the source tag along. The integrity of the source tag can be enforced by the static analysis tool during the CI phase.

7.4 Patch side effects audit mechanism: from path checking to state machine global consistency verification

The Linux kernel maintenance team should build a list of key state variables (critical state inventory) listing all “flags/reference counts/ownership pointers with cross-subsystem semantic invariance”. Any patch that modifies a variable in this list must be verified by the following three layers: (1) the correctness of the path of the patch itself; (2) the consistent regression of the variable on all propagation paths; and (3) the side-effect prediction of all dependent code paths triggered by the variable before and after the patch. Dirty Frag → Fragnesia’s “patch-spawned vulnerability” chain could have been blocked in the second layer of detection.

7.5 The “benefit-risk” assessment and clean-up strategy of legacy code.

Legacy components such as RxRPC/fcrypt, PCBC mode, and authencesn (if IPsec is fully migrated to AEAD GCM/ChaCha20-Poly1305 in the future) have “no more cryptographic value and code side effects”. It is recommended to establish a periodic “legacy encryption component audit” mechanism: (1) evaluate the actual call frequency in the actual production environment (rxrpc.ko is only used in a few scenarios); (2) evaluate its cryptographic strength (fcrypt 56-bit key can be violent); (3) evaluate the risk of code side effects (whether the in-place operation becomes an attack sink). Combine the three assessments to give a “maintain/deprecate/force refactoring” decision.

7.6 Mapping of the Concept of “Executive Governance”: Constraints, Auditing and Micro-defense-in-depth at the Operating Object Level

In many years of system security practice, Antiy has proposed “executive governance (Execution Entity Governance)” – that is, the basic unit of network security operation is fine-grained from “boundary” or “host” to “every running object that is actually loaded and given execution permission”. In the context of the Dirty family, the concept of “executive body” can be mapped to three levels in the future:

• Process/container-level execution body-whether AF_ALG socket can be opened, unshare can be triggered (CLONE_NEWUSER), and whether esp4/esp6/rxrpc modules can be loaded;
• Whether the page cache integrity of setuid programs such as/usr/bin/su and dynamic library pam_unix.so is verified in real time;
• AI Agent Execute-If the future AI agent runs as a system process, its ability to invoke the encrypted interface needs to be a new governance object (this is an extension of Antiy’s thinking of “prompt words (Prompt) as a new type of execution”).

For the Dirty family, the most direct executive governance practices include: (1) creating AF_ALG/AF_RXRPC socket by seccomp restricting processes in the non-governance whitelist; (2) limiting the CLONE_NEWUSER capability of non-container runtime processes by AppArmor/SELinux; (3) monitoring the page cache hash of setuid binary in real time through EDR; (4) Add the loading of modules such as esp4/esp6/rxrpc/algif_aead to the whitelist of the execution body. None of these measures alone constitute an “exhaustive loophole” solution, but their combination forms a micro defense-in-depth (micro-defense-in-depth) structure that blocks the vast majority of Dirty family variants in the window where the patch is not in place.

8. Conclusion and Future Prospects

8.1 Structural Law Summary: “Three-body” balance is dynamic evolution rather than static equilibrium.

The core structural rule given by the Dirty family is that there is no static balance between encryption mechanism, performance, and system security. The “temporary balance” at any point in time will be broken by changes in external conditions (hardware capabilities, attack paradigms, introduction of new features). Dirty Pipe reveals the zero-copy risk of the pure IO path; Copy Fail moves the risk to the encrypted path; Dirty Frag chains the risk and takes into account cross-release blind areas; Fragnesia escalates the risk to the level of patch side effects. The evolution of loopholes shows that the “three-body” balance is a dynamic evolution process, and each balance is the seed of the next imbalance.

8.2 Open Source Community Engineering Philosophy: From “Default Trust” to “Explicit Verification” to “State Machine Proof”

The implicit trust model of the past 30 years of Linux kernel engineering philosophy is: “the input passed to me upstream is good, I do my work on it, and then downstream according to its rules”. The Dirty family proves that the model is invalid when it comes to shared ownership (page caching) and cross-subsystem cryptographic hubs. The next stage of engineering philosophy should evolve from “default trust” to “explicit verification” – ownership, writability and sharing must be explicitly marked, and then to “state machine proof” based on AI computing platform support-key state variables must be checked by bounded models on all propagation paths.

8.3 Future security trends: primitive recognition, semantic annotation, chain deduction and prediction of repair side effects

In the next 1-3 years, four clear trends in Linux kernel security engineering can be foreseen:

1. AI-assisted primitive recognition (Primitive Identification) will be normalized – “zero-copy reference in-place write page cache source” and other modes will be included in the kernel CI as continuous scanning rules;
2. Semantic tagging system establishment-scatterlist, sk_buff, pipe_buffer and other core structures will gradually introduce ownership/source semantic tagging;
3. Instrumentalization of chain attack deduction-chain reachability between attack primitives will be analyzed by instrumentalization of graph algorithms;
4. Fix Side Effect Prediction – The patch incorporation process will introduce “Global Impact Prediction on Key State Variables” as a mandatory check.

In the context of Mythos, and GPT 5.5, which have brought great panic about the ability of AI to mine vulnerabilities, Xint Code has also built a human-machine collaborative vulnerability demonstration sample. On the one hand, Antiy recognizes that vulnerability mining is an important security capability, and vulnerability analysis and response repair is the basic security capability. But at the same time, I also want to emphasize once again that “vulnerabilities are not an object object”, and security efforts to eliminate vulnerabilities by exhausting them will be futile. In fact, the “emergence attribute” of the complexity of system environment and context conditions is the “relational existence” in the attack and defense process “. Exhaustive loopholes are neither possible nor should be a goal.

The reasonable goal of the defender should therefore shift from “exhausting loopholes” to “acknowledging the inevitability of the objective existence of loopholes, and putting resources into mitigating and weakening the attacker’s ability to use loopholes as an entry point”. Specific to the operational level, including:

8.4 Defense Inspiration: Out of the Mistake of Exhaustive Vulnerabilities and Constructing Micro-Defense in Depth at the Running Object Level

• Extreme exposure and attack surface governance-based on port, account, and service governance, the attacker’s accessibility conditions are completely weakened, and unused functions and capabilities are shut down as much as possible based on configuration optimization.
• Does not depend on the timeliness of the patch – in the patch is not in place in the window through the module blacklist, seccomp policy, AppArmor restrictions to block the use of preconditions;
• Real-time verification of the execution layer-real-time verification of the page cache integrity of the setuid binary, dynamic library, and key configuration files (/etc/passwd,/etc/sudoers);
• Fine-grained control of running objects-each execution body (executable file, process, container, module, AI agent) as an independent governance unit, giving the minimum required permissions;
• Threat intelligence and closed-loop operations-build the ability to regularize attack primitives on the terminal protection side, and incorporate them into the EDR/XDR rule base as general threat knowledge, which is combined with the reputation evaluation of the executive body.

These capabilities and governance methods are completely consistent with Antiy’s judgment that “the cornerstone of network security is back to the system side” and the product orientation of “fine-grained security boundaries to each execution object. It is not a “specific solution” of a certain vulnerability family, but a “general engineering attitude” in the face of the era of emerging vulnerabilities “.

(Several large model tools and intelligences were used in the preparation of this article for content generation and information retrieval verification, but the full content of the report has been manually reviewed, which is hereby explained)

Appendix References

[1] Antiy CERT. CVE-2026-31431 (Copy Fail) Vulnerability FAQ (Part I) – Basic Situation, Scope of Influence and Disposal of Vulnerability [R/OL]. (2026-05-12) [2026-05-18].

https://www.antiy.com/response/Copy_Fail_FAQ_01.html.

[2] Antiy CERT. CVE-2026-31431 (Copy Fail) Vulnerability FAQ (Part II) – Vulnerability Technical Mechanism, Historical Coordinates and Strategic Implications [R/OL]. (2026-05) [2026-05-18].

https://www.antiy.com/response/Copy_Fail_FAQ_02.html.

[3] Antiy Research Institute. A New Paradigm for Vulnerability Analysis of Human-AI Collaboration — Copy Fail Discovery Process Analysis [R/OL]. (2026-05) [2026-05-18].

https://www.antiy.com/response/Copy_Fail_Analysis.html.

[4] Antiy Research Institute. Thinking on “Attack Primtives” Based on Dirty Frag Vulnerability Discovery Process – Re-discussion on Human-Computer Division of Vulnerability Discovery and Analysis [R/OL]. (2026-05) [2026-05-18].

https://www.antiy.com/response/Dirty_Frag.html.

[5] Antiy Research Institute. “Fragment Amnesia” — How Dirty Frag Patch Promotes Fragnesia Vulnerabilities [R/OL]. (2026-05) [2026-05-18].

https://www.antiy.com/response/Dirty_Frag02.html.

[6] MITRE. CVE-2022-0847 [EB/OL]. (2022) [2026-05-18]. https://nvd.nist.gov/vuln/detail/CVE-2022-0847.

[7] KELLERMANN M. The Dirty Pipe Vulnerability [EB/OL]. (2022-03-07) [2026-05-18].

https://dirtypipe.cm4all.com /.

[8] MITRE. CVE-2026-31431 [EB/OL]. (2026) [2026-05-18]. https://nvd.nist.gov/vuln/detail/CVE-2026-31431.

[9] Xint Code Research Team. Copy Fail: 732 Bytes to Root on Every Major Linux Distribution [EB/OL]. (2026-04-29) [2026-05-18].

https://xint.io/blog/copy-fail-linux-distributions.

[10] MITRE. CVE-2026-43284, CVE-2026-43500 [EB/OL]. (2026) [2026-05-18]. https://nvd.nist.gov/vuln/detail/CVE-2026-43284.

https://nvd.nist.gov/vuln/detail/CVE-2026-43500.

[11] KIM H (V4bel). Dirty Frag Write-up [EB/OL]. (2026-05-07) [2026-05-18]. https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md.

[12] MITRE. CVE-2026-46300 [EB/OL]. (2026) [2026-05-18]. https://nvd.nist.gov/vuln/detail/CVE-2026-46300.

[13] BOWLING W. Fragnesia PoC and Write-up [EB/OL]. V12 Security Team. (2026-05-13) [2026-05-18].

https://github.com/v12-security/pocs/tree/main/fragnesia.

[14] DWORKIN M. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC: NIST SP 800-38D[S]. Gaithersburg: National Institute of Standards and Technology, 2007. NIST Crypto Publication Review Board 2024-03-05 revision decision.

https://www.nist.gov/news-events/news/2024/03/nist-revise-special-publication-800-38d-galoiscounter-mode-gcm-and-gmac

[15] KENT S. IP Encapsulating Security Payload (ESP): RFC 4303[S]. IETF, 2005-12.

https://www.ietf.org/media/documents/241209_IETF_RFC_Declaration_-_RFCs_4303_4304_4307_4308_4309_4543_4835_4868_599_8vOcsP5.pdf

[16] CHEN K T, KLASSERT S. [PATCH net 8/8] xfrm: esp: avoid in-place decrypt on shared skb frags[EB/OL]. netdev mailing list. (2026-05)[2026-05-18]. https://www.spinics.net/lists/netdev/msg1183448.html.

[17] CORBET J. Rethinking splice()[EB/OL]. LWN.net. (2023-02-17)[2026-05-18]. https://lwn.net/Articles/923237 /.

[18] CISA. Known Exploited Vulnerabilities Catalog: CVE-2026-31431[EB/OL]. (2026-05-01)[2026-05-18].

https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

[19] Microsoft Security Response Center. CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments[EB/OL]. (2026-05-01)[2026-05-18]. https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation /.

[20] Tenable Research Special Operations. Dirty Frag (CVE-2026-43284, CVE-2026-43500): Linux Kernel Privilege Escalation FAQ[EB/OL]. (2026-05-08)[2026-05-18].

https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe.

[21] Tenable Research Special Operations. Fragnesia (CVE-2026-46300): Linux Kernel ESP-in-TCP LPE FAQ[EB/OL]. (2026-05-14)[2026-05-18]. https://www.tenable.com/blog/fragnesia-cve-2026-46300-faq-about-new-linux-kernel-xfrm-esp-in-tcp-priv-esc.

[22] HOWELLS D. RxRPC Network Protocol[EB/OL]. The Linux Kernel Documentation. [2026-05-18].

https://docs.kernel.org/networking/rxrpc.html.

[23] Linux Kernel. net/rxrpc/Kconfig[EB/OL]. [2026-05-18]. https://github.com/torvalds/linux/blob/master/net/rxrpc/Kconfig.

[24] Antiy. Taking the governance of the executive body as the cornerstone, it helps the construction of intelligent civil aviation [R/OL]. (2023)[2026-05-18].

https://mp.weixin.qq.com/s/Qb0c-xA1fgqbxGZG2ASxCA.

[25] Antiy CERT. Claw Catastrophe-Analysis of Large-scale Poisonous Action for AI Agent OpenClaw Skill Market [R/OL]. (2026) [2026-05-18].

https://www.antiy.com/response/OpenClaw_AI_Poisoning_Attack_Analysis.html.

[26] Sysdig Threat Research Team. CVE-2026-31431: “Copy Fail” Linux kernel flaw lets local users gain root in seconds [EB/OL]. (2026-04-29) [2026-05-18]. https://www.sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds.

[27] Sysdig Threat Research Team. Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC[EB/OL]. (2026-05)[2026-05-18].

https://www.sysdig.com/blog/dirty-frag-cve-2026-43284-and-cve-2026-43500-detecting-unpatched-local-privilege-escalation-via-linux-kernel-esp-and-rxrpc.

[28] InfoQ. Copy Fail and Dirty Frag: Linux Page-Cache Exploits Target Every Major Distribution [EB/OL]. (2026-05) [2026-05-18]. https://www.infoq.com/news/2026/05/copy-fail-dirty-frag-linux /.

[29] AlmaLinux Project. Fragnesia (CVE-2026-46300): Patched kernels available[EB/OL]. (2026-05-13)[2026-05-18].

https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300.

[30] Canonical Ltd. Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability[EB/OL]. (2026-05)[2026-05-18]. https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available.

[31] BUGCROWD. What we know about Copy Fail (CVE-2026-31431) [EB/OL]. (2026-04-29)[2026-05-18].

https://www.bugcrowd.com/blog/what-we-know-about-copy-fail-cve-2026-31431.

[32] ARPA-H, DARPA. DARPA AI Cyber Challenge (AIxCC) Finals Results [EB/OL]. (2025-08) [2026-05-18].

https://arpa-h.gov/.

[33] Dark Reading. Dirty Frag Exploit Poised to Blow Up on Enterprise Linux Distros [EB/OL]. (2026-05) [2026-05-18]. https://www.darkreading.com/vulnerabilities-threats/dirty-frag-exploit-blow-up-enterprise-linux-distros.