“Fragment Amnesia”—How the Dirty Frag Patch Gave Rise to the Fragnesia Vulnerability
1. Introduction
1.1 Incident Retrospective: The “Chain of Vulnerabilities” from Dirty Frag to Fragnesia
In May 2026, the Linux kernel security community experienced a rare chain of security incidents. On May 4th, Kuan-TingChen submitted a patch based on the shared-frag method to the netdev mailing list. This patch introduced the SKBFL_SHARED_FRAG marking mechanism, intending to identify and block shared cache pages from splice() in the ESP input path. On May 7th, independent security researcher Hyunwoo Kim (@v4bel) publicly disclosed the Dirty Frag vulnerability via the oss-security mailing list—a local privilege escalation (LPE) vulnerability implemented by chaining together the xfrm-ESP (CVE-2026-43284) and RxRPC (CVE-2026-43500) page cache write primitives, affecting all major distributions including Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, and Fedora 44. The destructive nature of this vulnerability lies in its determinism: it requires no race conditions, is independent of kernel version differences, and a single primitive can overwrite the memory image of a setuid binary, achieving a CVSS score as high as 7.8. Under pressure, the Linux kernel maintainers responded swiftly. On May 7th, Steffen Klassert, the maintainer of the xfrm subsystem, guided the patch to be merged into the netdev tree; on May 8th, the patch (commit f4c50a4034e6) was merged into the mainline. The community once believed that the attack surface of Dirty Frag had been completely blocked.
However, approximately 5-6 days later, on May 13th, security researcher William Bowling— Head of Assurance and a member of the V12 Security team at Zellic — submitted a patch for Fragnesia to the netdev mailing list (Message-ID: 20260513041635.1289541-1-vakzz@zellic.io), officially disclosing Fragnesia (CVE-2026-46300). Its exploit path directly stems from the Dirty Frag patch—the SKBFL_SHARED_FRAG flag was lost in the merge path of skb_try_coalesce(), causing the patched kernel to open a new page cache write window. Attackers achieved precise byte-by-byte writing through AES-GCM keystream XOR, successfully overwriting the first 192 bytes of /usr /bin/ su in the PoC. This vulnerability also received a high CVSS score of 7.8. From Dirty Frag to Fragnesia, the interval wasn’t months, but only about a week. This is not a coincidence, but a classic case of patch-induced vulnerability: a patch designed to “cure” a vulnerability, under certain conditions, “spawns” a new attack surface.
1.2 The Evolutionary Paradox: Why Security Patches Become a Breeding Ground for New Vulnerabilities
Vulnerability response and remediation models follow a linear logic of “discovery-remediation-verification-closure”. However, the Fragnesia incident presents a non-linear paradox: the remediation itself alters the system’s state space, giving previously dormant vulnerabilities a new semantic context, thus “activating” them as exploitable vulnerabilities. This paradox can be viewed as a state machine complexity problem. A state machine is a behavioral logic model of fixed states based on triggering conditions and transition rules. The Linux kernel, with its entire set of resources, data structures, network buffers, and protocol flows, constitutes a complex global runtime state transition system. Therefore, its kernel is not a static collection of code but a dynamically evolving network of state machines. Any security patch—especially those introducing new markers, checkpoints, or branch paths — changes the state transition rules. If the patch designer lacks a complete understanding of the global topology of the state machine, newly introduced state variables may be “lost” or “mutated” in some transition paths, resulting in reachable states not anticipated by the patch designer. The fix for Dirty Frag is exactly this: it introduces a binary flag SKBFL_SHARED_FRAG, assuming that the flag will propagate correctly with the skb (socket buffer) throughout its lifetime.
However, skb undergoes dozens of operations in the kernel network stack, including allocation, cloning, merging, fragment, and freeing, each of which can alter its internal state. The patch designers verified the tag checking of the ESP input path but overlooked tag propagation in the skb_try_coalesce() merge path—an old bug that has existed since 2013 (commit cef401de7be8) and had never been triggered in 13 years. The Fragnesia patch points to two Fixes tags: cef401de7be8 in 2013 and f4c50a4034e6 in 2026. It’s important to clarify that, technically, Fragnesia wasn’t a new bug “introduced” by the Dirty Frag patch; rather, the Dirty Frag patch added code paths that relied on the correct SKBFL_SHARED_FRAG tag, making a 13-year-old coalescing bug exploitable for the first time.
1.3 The Metaphor of “Fragment Amnesia”: “Fragment Amnesia”—the Loss of Markers During skb Fragment and Merging—Is a Precise Metaphor for the Root Cause of Fragnesia.
Fragnesia is a construct by William Bowling based on the words Fragment (fragment, kernel network fragment) and nesia=Amnesia (amnesia, forgetfulness), hence this vulnerability is also translated into Chinese as “Fragment Amnesia”. `skb_try_coalesce()` is a kernel function responsible for merging fragments from two adjacent ` skb`s. Its design goal is to reduce memory allocation overhead and improve network throughput. In the Linux kernel network stack, `skb` (socketbuffer) is the core carrier of network packets. When packets are large or traverse zero-copy paths, the `skb` ‘s data area may consist of multiple fragments, each pointing to an independent memory page. This memory is read from the ESP input path. If it exists, a Copy-On-Write (COW) operation is forcibly triggered to prevent in-situ decryption from tampering with the shared page. The Dirty Frag fix patch introduces a “memory” for the skb —the SKBFL_SHARED_FRAG flag, defined in include/linux/skbuff.h (SKBFL_SHARED_FRAG=BIT(1)), used to identify that the skb contains a shared cache page from user-space splice(). However, when two skbs are merged by skb_try_coalesce(), this “memory” is selectively forgotten. The merged skb inherits the data content before the merge but loses the shared page flag. Thus, a cache page that should have been marked as “dangerous” enters the ESP-in-TCP decryption path as “clean” after the merge and undergoes the in-situ XOR operation of AES-GCM—Fragment Amnesia, the flag is reset to zero, and the attack occurs.
2. Benefits and Side Effects: The Dual Nature of Patches
2.1 Key Logic of Dirty Frag Repair: The SKBFL_SHARED_FRAG Flagging Mechanism
The core of the Dirty Frag attack lies in the attacker injecting cached pages of a setuid binary file (such as `/ usr /bin/ su` ) into the fragment region of a network skb using `splice()`. The skb then enters the `xfrm-ESP` or RxRPC decryption path, and the in-place decryption operation directly overwrites the shared cached pages, achieving privilege escalation. To fix this vulnerability, Kuan-Ting Chen submitted a patch (commit f4c50a4034e6), which was reviewed by maintainers such as Steffen Klassert and merged into the mainline. This patch employs a “mark-and-check” strategy. The marking phase: When `splice()` injects the cached pages into the skb fragment region, the `SKBFL_SHARED_FRAG` mark is set for the skb. The propagation phase: It is assumed that this mark will propagate correctly with skb cloning, referencing, and passing operations. The checking phase: In the ESP input path (`esp_input()`→`esp_input_done2()`), it checks whether the skb carries this mark. If carried, the in-place decryption operation will be forced to trigger skb_cow_data() for private copying, avoiding in-place decryption on the shared frag. This strategy appears complete in single-path verification: as long as the flag is set correctly and not tampered with before the ESP path, the attacker’s shared page injection will be blocked.
2.2 Boundary Assumptions for Repair: Tags Propagate Correctly Throughout the Entire skb Lifecycle.
The fix implicitly includes three boundary assumptions that together form the basis of the “sufficiency illusion”.
Assumption 1: Persistence of the tag. SKBFL_SHARED_FRAG, as part of the skb’s private tag, should remain persistent throughout all skb operations until the skb is released.
Assumption 2: Heredity of tags. When an skb is cloned (skb_clone()), copied (skb_copy()), or referenced, the tag should be correctly inherited.
Assumption 3: Closure of tags. skb fragment operations (such as adding, deleting, and merging fragments) should not result in tag loss unless the operation explicitly clears the shared attribute of the fragment. Each migration step may involve skb reallocation, fragment reorganization, or flag operations.
These three assumptions hold true in linear paths, but fail in nonlinear state transitions. The lifecycle of skb in the kernel network stack is not a simple linear transfer, but rather undergoes a complex graph-like state transition: network interrupt reception → GRO (Generic Receive Offload) aggregation → skb_try_coalesce() merging → protocol stack processing (TCP/UDP) → ULP (Upper Layer Protocol) switching (such as espintcp ) → xfrm decryption.
2.3 The Overlooked Corner: Silent Loss of Markers in High-Performance Merge Paths
skb_try_coalesce()` is to merge two adjacent skb (to and from) into one, thereby reducing the number of shards and improving cache locality. `skb_try_coalesce()` is a frequently optimized function in the kernel network stack, located in `net/core/ skbuff.c`.
Before the Dirty Frag fix, this behavior was insignificant— there were no shared page tags in the network stack that needed to be propagated across skbs. However, after the fix introduced SKBFL_SHARED_FRAG, the “no flag propagation” behavior of skb_try_coalesce() changed from a “harmless design choice” to a “dangerous flag loss”. Since its introduction in 2013, this function has undergone dozens of optimization iterations, but its core logic has remained unchanged: copying the shard pointer during merging, but not copying or merging the flags of the source skb. The reason the patch designers did not simultaneously audit skb_try_coalesce() was due to the “fix immunity” of performance-sensitive paths: this function is a hot path processed per packet, and adding any extra checks (such as flag propagation) would introduce branch prediction failures and memory access latency. When fixing Dirty Frag, the developers instinctively avoided modifying the hot path, choosing instead to add checkpoints at the “sufficiently safe” ESP path entry point.
2.4 Marking “Amnesia”: The Code Mechanism Behind the Loss of SKBFL_SHARED_FRAG After Merging
The precise mechanism of the lost tag is as follows: The scenario is that skb_a is injected by an attacker using splice() and carries the SKBFL_SHARED_FRAG tag; the fragment contains cached pages from /usr /bin/ su. skb_b is a normal network packet without shared page tags; the fragment contains kernel-private pages. The merging process is as follows:
- In the TCP receive path, skb_a and skb_b are continuously fed into skb_try_coalesce();
- The function merges the fragments of skb_a and skb_b into a new fragment array;
- The function releases the independent structures skb_a and skb_b and returns the merged skb_merged.
- skb_merged does not inherit SKBFL_SHARED_FRAG — the tag is missing;
- The merged skb_merged enters the TCP ULP switching path and is marked as espintcp (ESP-in-TCP).
- skb_merged enters the xfrm ESP-in-TCP decryption path;
- Since SKBFL_SHARED_FRAG is missing, the skb_has_shared_frag() check in esp_input_done2() returns false;
- AES-GCM performs in-situ decryption and execution, and the key stream is XORed to overwrite the shared cache page;
- /usr/bin/su was tampered with, triggering privilege escalation the next time it is executed;
The key issue is that lost tags are not “data corruption”, but rather a semantic break. The cached pages are still shared (_refcount >1), but the skb’s metadata no longer reflects this fact. Kernel security decisions rely on metadata rather than physical memory state; this “memory loss” of metadata directly leads to the failure of security policies. As William Bowling pointed out in the Fragnesia patch description: When skb_try_coalesce() appends a page fragment from @from to @to, if @from has the SKBFL_SHARED_FRAG flag set, the merged @to will still retain the original external ownership or page cache associated fragment, but will not inherit the shared page tag. Silent tag loss directly violates the kernel invariants upon which the in-place write protection mechanism for subsequent decryption paths relies.
Figure 1: The Fragnesia Attack Chain: From `splice()` to Privilege Escalation
3.The “Reactivation” of an Age-Old Flaw
3.1 Dormant Code from 2013: The History of the skb_try_coalesce() Flag Propagation Bug
skb_try_coalesce()` is not a newly introduced code bug, but rather a design inertia that has existed since 2013. The Fixes tag in the Fragnesia patch explicitly points to two commits:
Fixes: cef401de7be8 (“net: fix possible wrong checksum generation”) ← Submitted in 2013
Fixes: f4c50a4034e6 (“xfrm: esp: avoid in-place decrypt on shared skb frags”) ← Dirty Farg patch
In 2013, the Linux kernel network stack faced throughput pressure from 10GbE and even 40GbE network interfaces. The `skb_try_coalesce()` function was introduced to address cache jitter and memory allocation overhead caused by excessive skb fragment in high-bandwidth scenarios. Its design philosophy was to minimize metadata operations: only copying fragment pointers, not flags, and not updating any state other than reference counts. In the design context at the time, this choice was reasonable: -` skb-> shinfo-> tx_flags` was primarily used for hardware offload marking of the sending path (such as VLAN, TSO, checksum offload), and was unrelated to memory safety of the receiving path; – There was no concept of “shared cache pages” that needed to be propagated across skb; – The merging operation pursued extreme performance, and any additional bit operations were considered unnecessary overhead. Therefore, the “no flag propagation” of `skb_try_coalesce()` was not a bug, but a design assumption—one that was perfectly valid at the time but was overturned 13 years later by the Dirty Frag patch.
3.2 Why It Was Not Triggered for 13 Years: “Harmlessness” in the Absence of a Tagging Mechanism
A logical flaw that lay dormant for 13 years failed to materialize due to the persistent absence of pre-existing constraints upon which the vulnerability depended. Since its implementation in 2013, `skb_try_coalesce()` has consistently adhered to the inherent logic of copying only fragment data and not synchronously transmitting the skb flag during fragment merging. For a long period before the kernel introduced the `SKBFL_SHARED_FRAG` security flag, the network stack did not need to transfer shared page attributes and security metadata across skbs; merging only the frag data was sufficient to meet business and performance requirements. At this time, the failure to propagate the flag was simply a common historical design practice and posed no security risk. This problem can be likened to: a door that originally didn’t need a lock—no lock, no need for a lock— “cannot be locked” itself isn’t a flaw; only when a lock is subsequently added for security protection is it discovered that the door’s inherent structure is incompatible with the lock’s logic. After the Dirty Frag fix patch introduced SKBFL_SHARED_FRAG, it was equivalent to adding shared page protection verification to the network stack. However, the flag left by skb_try_coalesce() did not propagate the weakness, which immediately turned from a harmless design into a fatal flaw, ultimately causing the protection flag to be silently lost and the security policy to be bypassed.
3.3 The “Activation Effect” of the Dirty Frag Patch
Fragnesia lies in the fact that the patch didn’t fix the vulnerability; it activated it. The Dirty Frag patch introduced the SKBFL_SHARED_FRAG flag, intending to add a dimension to the security state machine. However, this new dimension led to an incompatible state machine evolution with the old code path (skb_try_coalesce()): in the new state machine, skb_try_coalesce() became an undefined transition—the patch designer didn’t consider how the flag should propagate under this path, and the old code didn’t handle the new flag. As a result, the system reverted to the default behavior of the old state machine (skb_normal), bypassing the newly introduced security checks. This “activation effect” is a typical pattern for patch-derived vulnerabilities: new code gives old vulnerabilities a new semantic context, allowing them to transition from an “unreachable state” to an “reachable and exploitable state”.
Figure 2: State Machine Diagram Illustrating How the Dirty Frag Patch Introduces the Fragnesia Vulnerability
3.4 The Transition from “Design Oversight” to “Vulnerabilities Arising from Patches”
Fragnesia’s state transitions reveal the evolution of vulnerability taxonomy: the peculiarity of patch-derived vulnerabilities lies in the complexity of their attribution of responsibility: the patcher does not introduce the original defect, but their patching action alters the system’s state space topology, making the original defect an attack path for the first time. This necessitates the security community establishing a patch side-effect auditing mechanism to incorporate the patching action itself into the scope of vulnerability research.
4. Patterns and Insights Regarding Vulnerabilities Arising from Patches
4.1 Three Pathways for Vulnerabilities Arising from Patches: Bypass, Degradation, Activation, and Historical Cases
Fragnesia case is a representative example of a patch “activation” vulnerability, but “activation” is only one path for patch-derived vulnerabilities. Based on the analysis of multiple historical patch-derived vulnerabilities, we categorize these paths into three types: bypass, degradation, and activation. Another scenario involves attackers posing as patchers to construct vulnerabilities within the patch. A typical example is the XZ Utils backdoor incident (CVE-2024-3094), where attackers impersonated patchers or contributors to directly construct vulnerabilities within the patch. However, this involves social engineering and is beyond the scope of this discussion at Antiy. We will address this topic in a future article.
The following are some classic historical cases, which are used to analyze the mechanisms of the three derivative paths.
Table 1: Classification of Patch-Derived Vulnerabilities and Historical Examples
| Patch-derived vulnerability types | Type description | Historical vulnerability cases |
| Bypass | The patch added checkpoints (such as permission verification, boundary checks, and state verification), but attackers found alternative paths to bypass these checkpoints by analyzing the control flow changes introduced by the patch, rendering the security checks ineffective. | GC BUG_ON Bypass Vulnerability ( CVE-2021-0920 ) In the Android Linux kernel GC (garbage collection) subsystem, a bug introduced by a patch, the _ON check, can be bypassed, leading to privilege escalation. |
| The nft_tables Check Bypass vulnerability ( CVE-2022-34918) indicates that the patch verification logic of the nftables subsystem is incomplete, allowing attackers to bypass type checking and execute arbitrary code. | ||
| Netfilter Compat Bypass Vulnerability ( CVE-2021-22555 ) The netfilter compatibility layer patch did not cover all compat paths, causing security checks to be bypassed in 32-bit compatibility mode. | ||
| Degradation | The patch added checkpoints (such as permission verification, boundary checks, and state verification), but attackers found alternative paths to bypass these checkpoints by analyzing the control flow changes introduced by the patch, rendering the security checks ineffective. | io_uring Timeout Race vulnerability ( CVE-2022-29582 ) occurs when the logic for fixing/optimizing the io_uring timeout mechanism itself becomes a source of race conditions, leading to privilege escalation. |
| The XFRM Namespace Race vulnerability ( CVE-2022-3028 ) unintentionally introduced a race condition in a patch that added XFRM namespace support, leading to information leakage and User-Avoidance Defeat (UAF). | ||
| The io_uring GC UAF vulnerability ( CVE-2022-2602 ) involves the interaction between optimizations to the io_uring registry file and the Linux garbage collection mechanism, which generates a new UAF window. | ||
| Activation | The patch introduces new flags, state machines, or mechanisms, but is incompatible with existing code paths, causing previously untriggerable dormant bugs to become exploitable for the first time in the new semantic context. | The tcindex Reference Count vulnerability ( CVE-2023-1281 ) introduces a synchronization mechanism incompatible with existing workflows, which activates a hibernation reference counting flaw. |
| The SYSCTL Stack Overflow vulnerability ( CVE-2022-4378 ) is a stack overflow defect in the sysctl subsystem that had been dormant for 13 years, activated by the cumulative effect of multiple patches. | ||
| The QFQ Out-of-Bounds Write vulnerability ( CVE-2023-31436 ) is caused by multiple historical changes being overlaid on the QFQ scheduler patch, which activates the out-of-bounds write vulnerability and leads to kernel memory corruption. | ||
| The Fragnesia (Marking Loss) vulnerability ( CVE-2026-46300 ) introduces the SKBFL_SHARED_FRAG marker in the Dirty Frag patch. This marker is lost in the skb_try_coalesce() merge path, leading to a page cache write attack. |
Type 1: Bypass
This type of patch adds checkpoints (such as permission verification, boundary checks, and state verification), but attackers find alternative paths to bypass these checkpoints by analyzing the control flow changes introduced by the patch, rendering the security checks ineffective.
Key features:
Typical Case: CVE-2021-0920 — Linux GC BUG_ON Check Bypass
In 2017, Google’s Andrey Ulanov submitted a patch that added a BUG_ON() check to the unix_notinflight() function. The original patch was intended to prevent inconsistent flight counts through state verification. This vulnerability was first disclosed by Red Hat kernel developers in a public mailing list in 2016, but the Linux kernel community did not accept the patch at the time.
Attack principle
The BUG_ON() check appears to prevent UAF exploitation, but attackers have discovered that they can bypass the check by creating a large number of fake garbage objects to delay garbage collection.
Creating flying objects: Sending a large number of file descriptors via SCM_RIGHTS creates a large number of flying file objects.
Heap spray layout: Controlling memory layout by filling the slab cache with heap spray.
Race condition triggering: Utilize race conditions to trigger the MSG_PEEK operation during GC execution.
Bypassing the check: The GC’s BUG_ON check is bypassed due to the delay of fake garbage objects, allowing attackers to gain access to the sk_buff ‘s UAF primitive.
The Google Project Zero blog named this vulnerability “The Quantum State of Linux Kernel Garbage Collection”, which vividly describes how attackers can exploit the uncertainty of GC state.
Scope of influence
Wilderness utilization
Wintego since November 2020.
Repair plan
The 2021 official patch adds a request for a `unix_gc_lock` spin lock in the `MSG_PEEK` branch, forcing `MSG_PEEK` to wait for the GC to complete before executing.
Type 2: Degradation
In an attempt to reduce the attack surface or add security mechanisms, this type of patch actually lowers the attack threshold or expands the exploitable attack window. The patching logic itself becomes a source of race conditions, state inconsistencies, or reference counting errors.
Key features:
Typical Case: CVE-2022-3028—XFRM Namespace Patch Introduces Race Condition
XFRM subsystem and the afkey module added network namespace support. This patch aims to allow the IPSec/XFRM framework to work independently in different network namespaces. This is a normal feature enhancement patch.
Attack principle
Patch-derived exploit: A patch that added namespace support inadvertently introduced a race condition.
Key degradation feature: A feature enhancement patch (adding namespace support) turns a previously safe single-threaded code path into a multi-threaded race condition, which is a typical example of attack surface expansion.
Scope of influence
Repair plan
Commit: Add a mutex lock to the xfrm_probe_algs() call in the pfkey_register function to eliminate concurrency race conditions.
Type 3: Activation
This type of patch introduces new flags, new state machines, or new mechanisms, but is incompatible with existing code paths, causing previously untriggerable dormant bugs to become exploitable for the first time in the new semantic context.
Key features:
Typical Case: CVE-2023-31436—QFQ 2011 Patch Activated Out-of-Bounds Write
pkt_sched:enable QFQ to support TSO/GSO”) in 2011 added support for TSO (TCP Segmentation Offload) and GSO (Generic Segmentation Offload) to the QFQ (Quick Fair Queueing) scheduler. This patch modified the qfq_change_class() function so that it could directly use the network card’s MTU as the lmax value.
Attack principle
Patch-derived exploit: A feature enhancement patch from 12 years ago has become exploitable for the first time under certain configurations.
- lmax when the TCA_QFQ_LMAX parameter is not provided.
- The MTU of a loopback network card can be set to 2^31-1 (this is an existing but unrecognized system feature).
- An excessively large MTU caused the index i calculated by qfq_calc_index() to exceed the range of the q->groups array (which is only 25 in size).
- `agg->grp=&q->groups[i]` triggers slab-out-of-bounds write.
Key activation feature: The 2011 patch seemed perfectly safe at the time (using MTU as the default was a reasonable design choice), but with the introduction of the feature in the kernel that allowed the loopback MTU to be adjusted to an extremely large value, the old default path became exploitable for the first time. The new feature (extremely large MTU) was incompatible with the old patch code, activating the hibernation vulnerability.
Scope of influence
Repair plan
Commit: 3037933448f60f9acb705997eae62013ecb81e0d
The patch refactors the verification logic to ensure that a uniform boundary check is performed regardless of whether lmax is explicitly provided or derived from MTU.
Summary of the Comparison of the Three Types
Fragnesia is an activation type, which is the most insidious and unpredictable form because it requires the fixer to have a complete understanding of the code design assumptions accumulated over many years. The SKBFL_SHARED_FRAG flag introduced by the Dirty Frag patch is incompatible with the design assumption of skb_try_coalesce() in 2013 (“flags do not need to be propagated”), ultimately activating the flag propagation flaw that had been dormant for 13 years.
4.2 “The Illusion of Sufficiency”: A Cognitive Bias in Assessing Coverage
The “illusion of sufficiency” is the psychological root cause of vulnerabilities arising from patches; it stems from the belief that “what I’ve done is enough”. When verifying patches, developers often focus on covering direct attack paths while neglecting the completeness of indirect state transition paths:
Figure 3: The Illusion of Sufficiency: A Comparison of the Linear Path of the Repairer and the Graph Traversal of the Attacker
The app patcher’s verification follows a linear approach (from entry point to checkpoint), while the attacker’s exploit uses a graph traversal approach (all possible state transition paths). This cognitive asymmetry leads to a “sufficiency illusion” —the patcher believes “I have covered all paths”, when in reality they have only covered the expected paths. This cognitive bias at the level of thinking causes patch testing to focus only on the mainstream business flow, deliberately ignoring peripheral execution paths such as less common merging, asynchronous scheduling, and cross-module linkage, failing to exhaustively cover all transition branches of the kernel state machine. Ultimately, this results in newly added security constraints and state flags only taking effect in regular processes, leading to vulnerabilities such as rule invalidation and state loss in code logic that developers had not considered.
4.3 Why Was the “Repair Immunity” of Performance-Sensitive Paths Not Audited in Conjunction with the Merged Optimization?
`skb_try_coalesce()` was not audited synchronously lies in the “fix immunity” of performance-sensitive paths: this “fix immunity” makes performance-optimized code a blind spot for security fixes. The Fragnesia case shows that the older the optimized code, the more likely it is to become a compatibility trap for new security mechanisms.
4.4 Key Audit Points: From “Path Checking” to “Global Consistency Verification of State Machines”
Fragnesia requires an upgrade of the vulnerability auditing paradigm from “path checking” to “state machine global consistency verification”. Specific auditing recommendations include: Tag propagation closure audit: verify the propagation logic of new tags for each of the skb ‘s operation functions (approximately 50+ core functions); Cross-subsystem impact analysis: the introduction of tags affects not only this patched subsystem (xfrm) but also all subsystems consuming skb (TCP, UDP, SCTP, netfilter, QoS, etc.); Historical code compatibility audit: backtrack the skb operation functions introduced between 2013 and 2020 to verify whether they assume “the flag does not need to be propagated”.
5. Summary
5.1 The Open-Source Community Is Currently Facing the Dual Challenges of AI-Assisted Vulnerability Discovery and AI-Assisted Attacks
Linux has established a highly complex and sophisticated open-source operating system, including a tiered maintainer system, mailing lists and collaborative development platforms, rigorous code signing and review processes (such as Reviewed-by and Signed-off-by), automated continuous integration testing (such as Kernel CI), regular version release management (such as merge windows and rc version iterations), security vulnerability response teams (such as the Linux Kernel Security Team), CVE allocation mechanisms, community codes of conduct, and arbitration rules. These mechanisms ensure that Linux is a masterpiece of human ingenuity. However, it must be recognized that while it possesses extremely strict auditing mechanisms, this self-organized community and volunteer-driven operating mechanism struggles to effectively keep up with the vulnerability discoveries of new vulnerability researchers supported by large-scale AI computing power. The core issue is that the open-source community lacks sufficient and unified computing resources — the computing resources available to developers and reviewers are limited and highly uneven. Therefore, further adapting to the challenges posed by new attack actors with supercomputing power will involve a longer period of adjustment.
AI agents can complete code traversal and pattern matching that would take traditional human auditors weeks in just a few hours, compressing the vulnerability discovery window from “monthly” to “daily”. In terms of coverage, AI is not limited by attention fatigue and cognitive bias, and can perform consistency checks on code across subsystems and versions, discovering deep interaction defects that are difficult for humans to reach. In terms of continuity, AI can monitor code repository changes 24/7 and start side effect analysis the moment a patch is released. This “instant response” capability is unmatched by any human team.
Of course, we consistently oppose overestimating the capabilities of AI. Currently, AI still has limitations in understanding complex business logic and inferring deep design intentions. While Fragnesia’s findings utilized AI to traverse code paths, they were still based on the transformation and guidance of researchers’ analytical primitives. AI is an amplifier, not a replacement—it expands the analytical scope of security researchers, but core insights and engineering judgments still require human guidance. In the next three to five years, “AI initial screening – expert refinement – automated verification” will become the standard workflow. Open-source systems also need access to open computing power support.
5.2 Using AI-Assisted State Machine Verification to Counter AI-Assisted Vulnerability Discovery
Fragnesia can be precisely attributed to state machine inconsistency: the Dirty Frag patch introduced a new state, SKBFL_SHARED_FRAG, to skb, but failed to update the skb_try_coalesce() state transition function simultaneously. This caused a conflict between the new rule of “flags should be propagated” and the old implementation of “flags should not be copied”. This is a typical case of a lack of state machine verification—the patch changed the definition of the system’s state space but failed to verify whether all transition paths were consistent with the new definition.
The Linux kernel is essentially a massive state machine network. With skb as its core, its state variables (flags, tx_flags, frag lists, etc.) flow between dozens of core functions, each function representing a state transition rule. Security patches frequently introduce new state variables or constraints, such as the SKBFL_SHARED_FRAG flag, new reference counting semantics, and additional permission check bits. Each introduction theoretically requires verification: whether the variable is correctly propagated across all possible transition paths, not accidentally cleared, and not incorrectly overwritten. Manually performing this global consistency verification is virtually impossible— skb involves over 50 core operation functions, spanning more than ten subsystems including TCP, UDP, xfrm, and netfilter, resulting in an exponential increase in state transition paths.
AI-assisted state machine verification is a systematic solution to this challenge. Its core idea is to model changes to the kernel data structure as state machine patches, using AI to automate three key verifications. First, propagation closure verification: When a new tag is introduced, AI automatically traverses all functions that consume or modify the data structure, identifying which functions explicitly handle the new tag and which omit processing logic. If the Dirty Frag patch passes this verification, the missing SKBFL_SHARED_FRAG propagation code in skb_try_coalesce() will be automatically marked. Second, cross-subsystem consistency verification: AI constructs a data flow graph between subsystems, tracing the complete path of the new tag from its introduction point to all consumption points. SKBFL_SHARED_FRAG is defined by the xfrm subsystem but is silently cleared during the TCP receive path merging operation—this cross-subsystem semantic break is precisely where AI graph analysis has a natural advantage. Third, historical hypothesis conflict detection: AI learns code patterns to identify implicit hypotheses in historical functions that are incompatible with the new semantics. The 13-year design inertia of skb_try_coalesce() “only copies fragmented data and does not propagate flags” and the new security requirement of SKBFL_SHARED_FRAG “must propagate across skb ” can be detected in advance by AI.
AI possesses a highly weaponizable characteristic. AI-driven vulnerability discovery tools can reverse-engineer boundary assumptions within hours of a patch release, quickly identifying uncovered migration paths— Fragnesia’s disclosure from the inclusion of the Dirty Frag patch to its current state exemplifies this trend. The defense must respond with equivalent AI capabilities: not by countering AI scanning with manual auditing, but by using AI state machine construction to counter AI vulnerability discovery. Specifically, this requires embedding an “AI state machine consistency checkpoint” into the patch release process—patches must undergo AI verification before inclusion to confirm the complete propagation closure of new state variables across all migration paths; after release, continuous AI monitoring should be initiated to track abnormal state migration patterns.
The industrialization of this paradigm is already in its infancy. The DARPA AI Cyber Challenge has validated the practical value of AI in automated code analysis. The next key step is to shift this capability from “attack detection” to “defense verification”. In the next three to five years, “AI state machine pre-inspection – expert confirmation – continuous monitoring” is expected to become the standard release process for kernel security patches. We look forward to the next time, AI state machine verification will be able to intercept “new Fragnesia” before release.
5.3 Fixing Is Not the End; It Is the Beginning of New Risks.
Traditional vulnerability response models view “pattern release” as the end of an event—the patch is integrated into the mainline, the release is completed, the security alert is lifted, and the community moves on to the next issue. However, Fragnesia reveals a long-overlooked truth: patch release is not the end of a risk cycle, but rather the beginning of a new one.
From an attacker’s perspective, the public release of a patch is essentially a “reverse engineering guide”. After the Dirty Frag patch was merged into the mainline on May 8th, its code changes, the SKBFL_SHARED_FRAG marking mechanism, and the ESP path checking logic were all made public. For attackers with kernel analysis capabilities, this patch itself is an “attack map”—it indicates which paths are covered and also suggests which paths might be overlooked. William Bowling discovered Fragnesia approximately 5 to 6 days after the patch release precisely by focusing on analyzing the patch and reverse-engineering its boundary assumptions. History has repeatedly validated this pattern: attackers quickly locate uncovered alternative paths by analyzing the boundary checks in the patch. The conversion cycle “from patch to exploit” is being significantly shortened.
From a system evolution perspective, the patch altered the topology of the kernel state machine, and this change is inherently unpredictable. The Dirty Frag patch introduced the SKBFL_SHARED_FRAG flag, intended to add a security dimension, but it caused semantic breaks when interacting with the merge path of skb_try_coalesce(). This problem of “new state variables being incompatible with old code” is almost impossible to completely avoid through static review in large systems. More critically, there is the asymmetric risk—defenders need to verify correctness across the entire state space, while attackers only need to find an uncovered path. In Fragnesia, the designers verified the ESP path but overlooked a frequently used merge function that had existed since 2013.
From the user’s perspective, the misconception that “fixing equals security” can lead to lax defenses. Many organizations only perform basic regression testing after patch releases, lacking specific verification of “side effects”; some teams even delay updates for extended periods. Fragnesia demonstrates that such delays can expose systems to the dual threats of old and new vulnerabilities simultaneously—if the system is in an intermediate state between Dirty Frag’s fix and Fragnesia’s fix, attackers can exploit vulnerabilities derived from that patch to escalate privileges. Agility in patch management itself has become a critical variable in security.
From an industry ecosystem perspective, Fragnesia exposed weaknesses in the “patching-distribution” chain of the open-source supply chain. Kernel patches experienced delays of several days to weeks from being merged into the mainline to adoption by various distributions. During this period, the code was publicly available, but protection was not deployed, creating a vulnerable window of “code visible but protection lacking”. For enterprise users, establishing a patch pre-research mechanism—conducting side effect audits and stress tests after official release but before formal deployment—will become standard practice for security operations. For the kernel community, exploring a “tiered release” mechanism, allowing critical fixes to be first released to trusted parties for verification before being fully made public, is worth serious consideration.
The AI era offers new possibilities for patch risk management. AI-assisted state machine verification can detect issues like “markers being lost in the merge path” before release; however, AI-driven vulnerability discovery is also lowering the barrier for attackers to discover side effects. This game of “AI attack and AI defense” requires the patching process to shift from “manual design – manual review – manual release” to a closed loop of “AI-assisted design – AI global verification – tiered release – continuous monitoring”.
Fragnesia ‘s ultimate lesson is that security has no end, only a continuously evolving cycle of risk. Every patch reshapes the system’s state space, and this reshaping inevitably brings new unknowns. Accepting this is a clear-headed understanding of the nature of complex systems.
5.4 Patches Remain an Essential, Fundamental Security Mechanism
The Fragnesia incident easily leads to a misjudgment—since patches may create new vulnerabilities, wouldn’t it be safer to completely abandon patching? This question seems reasonable, but it actually misunderstands the fundamental security nature of complex information systems. System patching remains, and will always remain, the most basic and essential security capability for complex systems. This incident precisely illustrates that: patching capabilities on the product side need to keep pace with the AI era, and users need a more comprehensive patching strategy.
The choice between patching derivative vulnerabilities and not patching known vulnerabilities is essentially a probabilistic trade-off. Unpatched vulnerabilities are in a deterministic state of exposure—attackers have a complete analysis window, public proof-of-concept (PoC), and predictable paths, and the probability of exploitation increases over time. Before Dirty Frag’s patch, anyone with the details could reliably reproduce the attack. However, patch-derived vulnerabilities require multiple coupled conditions: semantic conflict between the new mechanism and historical code paths, activation of that path during actual operation, and the attacker’s initial discovery of the hidden interaction. Fragnesia’s patching and disclosure took only 5 to 6 days, precisely illustrating its low-probability, short-window characteristics. Weighing the two evils, the former is still a significantly better choice. Hostile patches only leave the system exposed to known vulnerabilities for a long time—precisely the scenario attackers desire most.
Complex information products inevitably possess incompleteness. Take Linux as an example: the kernel exceeds 30 million lines of code, involving thousands of developers and hundreds of subsystems. The ideal of “write once, never again” is impossible—not due to insufficient engineering capabilities, but rather determined by the inherent properties of complex systems. Formal verification, static analysis, and dynamic testing each have their limitations and cannot exhaustively cover all possible combinations of states. Patching is not a remedy for a “perfect design”, but rather a rational practice that acknowledges incompleteness and strives to approach higher levels of security through continuous iteration.
Practice has proven that patches are the most fundamental mechanism for addressing security and functional vulnerabilities. From Heartbleed to EternalBlue, from Spectre /Meltdown to Linux kernel privilege escalation vulnerabilities, the final closure of almost all major security incidents relies on patches. Mitigation measures such as IDS rules, endpoint protection, micro-segmentation, and zero trust are positioned to mitigate risks and break attack chains, not to eliminate the root cause; their core value lies in buying time for patch fixes, and relying on them long-term is a misconception.
In the AI era, patching capabilities need proactive upgrades. AI-assisted code analysis promises to push side-effect auditing towards automated global consistency checks; simultaneously, AI-driven vulnerability discovery is accelerating, shortening the cycle for attackers to discover new flaws. Under this trend, the demand for dynamic hot patches will increase—they can instantly fix critical vulnerabilities without downtime, compressing the attack window and buying valuable time for the comprehensive verification and official release of traditional patches. Developers must build a dual-track system of “dynamic hot patch emergency response + conventional patch eradication”, using a more agile and intelligent R&D and release mechanism to address security threats, using AI to combat AI. On the user side, a risk-based patch management strategy should be established: critical patches should be deployed as soon as possible after verification, while monitoring and rollback mechanisms should be established.
Fragnesia is not “patches are too dangerous, never apply them”, but rather “patters need to be wiser and need more AI assistance”. Patching vulnerabilities should prompt the community to introduce stricter semantic consistency checks throughout the patching process, rather than undermine confidence in the patching mechanism itself.
In short: When it comes to balancing security and functionality in complex systems, patches remain an indispensable solution.
Appendix
Appendix A: The code snippet and fix solution for marking the propagation defect of skb_try_coalesce()
A.1 Defect Code Analysis
`skb_try_coalesce()` function, located in `net/core/skbuff.c`, has a core defect in its flag propagation mechanism: it fails to synchronize the `SKBFL_SHARED_FRAG` flag of the source skb during merging of fragments. The following is the problem pattern described in the Fragnesia patch (committed by William Bowling, Message-ID: 20260513041635.1289541-1-vakzz@zellic.io).
A.2 Triggering Conditions
The triggering of a lost tag requires the following chain of conditions to be met: Tag setting phase: The attacker injects a cached page into the skb fragment region via splice()+MSG_SPLICE_PAGES. The TCP stack sets the SKBFL_SHARED_FRAG tag for the skb after skb_splice_from_iter(). Merging trigger phase: The skb carrying the SKBFL_SHARED_FRAG tag undergoes skb_try_coalesce() merging in the TCP receive path, resulting in tag loss. Check bypass phase: The merged skb enters the ESP-in-TCP decryption path, skb_has_shared_frag() returns false, skipping the skb_cow_data() call. Write execution phase: AES-GCM performs in-situ decryption and performs keystream XOR on the shared cached page, precisely overwriting the target file content. ####A.3 Fragnesia upstream fix patch: The core diff of the Fragnesia fix patch submitted by William Bowling.
– Fixes: cef401de7be8 (This patch adds the Fixes tag “net: fix possible wrong checksum generation” in two places) — a markup propagation defect that existed when skb_try_coalesce() was introduced in 2013. – Fixes: f4c50a4034e6 (“xfrm: esp: avoid in-place decrypt on shared skb frags”) — a Dirty Frag fix.
Appendix B: Simplified Diagram of the Fragnesia Trigger Path
Note: The following diagrams have been described in detail in the text of each chapter. This appendix provides a complete overview of data flow and control flow.
Appendix C: List of References
The references listed in this appendix are numbered in the order of their citation in the text, and the format follows GB/T 7714-2015 “Rules for Bibliographic References in Information and Documentation”.
KIM H. Dirty Frag: Linux kernel LPE via xfrm-ESP and rxrpc page-cache write[EB/OL]. (2026-05-07)[2026-05-15]. https://github.com/V4bel/dirtyfrag.
[2] KELLERMANN M. Dirty Pipe – CVE-2022-0847 [EB/OL]. (2022-03-07)[2026-05-15]. https://dirtypipe.cm4all.com/.
[3] SUSE. Solution Security Risk Report 2022: Dirty Pipe (CVE-2022-0847) [R]. SUSE, 2022. https://documentation.suse.com/sbp/security/pdf/SBP-SUSE-security-report-2022_en.pdf.
[4] HG TECH. Why Linux Keeps Getting Rooted by the Same Bug Class: The Page Cache Curse [EB/OL]. (2026-05-10)[2026-05-15]. https://thehgtech.com/articles/dirty-frag-page-cache-curse-2026.html.
[5] LINUX KERNEL SOURCE TREE. commit f4c50a4034e6 – xfrm: esp: avoid in-place decrypt on shared skb frags[EB/OL]. (2026-05-07)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c50a4034e6.
[6] RECONIX. Dirty Frag: How a Linux Kernel Embargo Failed in Public View[EB/OL]. (2026-05-08)[2026-05-15]. https://reconix.co/th/blog/dirty-frag-linux-zero-day-lpe/.
[7] Linux Kernel Organization. splice(2) – Linux manual page [EB/OL]. (2025-09-20)[2026-05-15]. https://man7.org/linux/man-pages/man2/splice.2.html.
[8] LINUX KERNEL DOCUMENTATION. XFRM (IPsec transform) subsystem documentation [EB/OL]. (2026)[2026-05-15]. https://docs.kernel.org/networking/xfrm.html.
[9] RECONIX. Dirty Frag: How a Linux Kernel Embargo Failed in Public View [EB/OL]. (2026-05-08)[2026-05-15]. https://reconix.co/th/blog/dirty-frag-linux-zero-day-lpe/.
[10] CYBERSCOOP. ‘Copy Fail’ is a real Linux security crisis wrapped in AI slop [EB/OL]. (2026-05-04)[2026-05-15]. https://cyberscoop.com/copy-fail-linux-vulnerability-artificial-intelligence/.
[11] ANTIY LABS. Thinking of “Attack Primitive” Based on Dirty Frag Vulnerability Discovery Process [EB/OL]. (2026-05-09)[2026-05-15]. https://www.antiy.net/p/thinking-of-attack-primitive-based-on-dirty-frag-vulnerability-discovery-process-re-discussion-on-human-machine-division-of-vulnerability-discovery-and-analysis/.
[12] Palo Alto Networks Unit 42. Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years [EB/OL]. (2026-05-05)[2026-05-15]. https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/.
[13] LINUX KERNEL SOURCE TREE. commit a664bf3d603d – Revert “crypto: algif_aead – fix AEAD decryption for assoclen” [EB/OL]. (2026-04-01)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603d.
[14] BOWLING W. [PATCH net] net: skbuff: preserve shared-frag marker during coalescing [EB/OL]. netdev mailing list, (2026-05-13)[2026-05-15]. https://lists.openwall.net/netdev/2026/05/13/79.
[15] National Vulnerability Database. CVE-2024-50264 [EB/OL]. (2024-11-19)[2026-05-15]. https://nvd.nist.gov/vuln/detail/CVE-2024-50264.
[16] Linux Kernel Organization. vmsplice(2) – Linux manual page [EB/OL]. (2025-09-21)[2026-05-15]. https://man7.org/linux/man-pages/man2/vmsplice.2.html.
[17] BOWLING W. Fragnesia: Linux kernel LPE via XFRM ESP-in-TCP[EB/OL]. (2026-05-13)[2026-05-15]. https://github.com/v12-security/pocs/tree/main/fragnesia.
[18] LINUX KERNEL DOCUMENTATION. sk_buff data structure and network packet processing [EB/OL]. (2026)[2026-05-15]. https://docs.kernel.org/networking/skbuff.html.
[19] LINUX KERNEL SOURCE TREE. net/core/skbuff.c – skb_try_coalesce() implementation [EB/OL]. (2026-05-13)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/skbuff.c.
[20] LINUX KERNEL SOURCE TREE. include/linux/skbuff.h – SKBFL_SHARED_FRAG flag definition[EB/OL]. (2026-05-07)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/skbuff.h.
[21] LINUX KERNEL SOURCE TREE. include/linux/skbuff.h – SKBFL_SHARED_FRAG flag definition[EB/OL]. (2026-05-07)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/skbuff.h.
[22] BOWLING W. [PATCH net] net: skbuff: preserve shared-frag marker during coalescing[EB/OL]. (2026-05-13)[2026-05-15]. https://lore.kernel.org/netdev/20260513041635.1289541-1-vakzz@zellic.io/.
[23] BOWLING W. [PATCH net] net: skbuff: preserve shared-frag marker during coalescing[EB/OL]. (2026-05-13)[2026-05-15]. https://lore.kernel.org/netdev/20260513041635.1289541-1-vakzz@zellic.io/.
[24] BOWLING W. [PATCH net] net: skbuff: preserve shared-frag marker during coalescing[EB/OL]. (2026-05-13)[2026-05-15]. https://lore.kernel.org/netdev/20260513041635.1289541-1-vakzz@zellic.io/.
[25] LINUX KERNEL SOURCE TREE. commit f4c50a4034e6 – xfrm: esp: avoid in-place decrypt on shared skb frags[EB/OL]. (2026-05-07)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c50a4034e6.
[26] LINUX KERNEL SOURCE TREE. net/ipv4/tcp_ulp.c – TCP ULP (Upper Layer Protocol) framework[EB/OL]. (2026)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_ulp.c.
[27] LINUX KERNEL DOCUMENTATION. ESP-in-TCP (espintcp) – IPsec ESP over TCP connections[EB/OL]. (2026)[2026-05-15]. https://docs.kernel.org/networking/epsintcp.html.
[28] LINUX KERNEL SOURCE TREE. commit cef401de7be8 – net: fix possible wrong checksum generation [EB/OL]. (2013-10-28)[2026-05-15]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cef401de7be8.
[29] Google Project Zero. 0-day in the Wild: CVE-2021-0920[EB/OL]. (2021-11)[2026-05-15]. https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-0920.html.
[30] CVE-2021-0920 Vulnerability Analysis (Chinese) [EB/OL]. (2023-05-10)[2026-05-15]. https://bsauce.github.io/2023/05/10/CVE-2021-0920/.
[31] KIM H. Dirty Frag: Linux kernel LPE via xfrm-ESP and rxrpc page-cache write [EB/OL]. (2026-05-07)[2026-05-15]. https://github.com/V4bel/dirtyfrag.
[32] KIM H. oss-security – Dirty Frag disclosure [EB/OL]. (2026-05-07)[2026-05-15]. https://www.openwall.com/lists/oss-security/2026/05/07/8.
[33] CVE-2022-29582 Detailed Analysis [EB/OL]. (2022-08-05)[2026-05-15]. https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/.
[34] Wiz Vulnerability Database. CVE-2022-29582[EB/OL]. (2022-04)[2026-05-15]. https://www.wiz.io/vulnerability-database/cve/cve-2022-29582.
[35] Wiz Vulnerability Database. CVE-2022-3028[EB/OL]. (2022-09)[2026-05-15]. https://www.wiz.io/vulnerability-database/cve/cve-2022-3028.
[36] openEuler. CVE-2022-3028 Track [EB/OL]. (2022)[2026-05-15]. https://gitee.com/src-openeuler/kernel/issues/I5OPA4.
[37] CVE-2022-2602 Vulnerability Analysis (Chinese) [EB/OL]. (2023-06-08)[2026-05-15]. https://bsauce.github.io/2023/06/08/CVE-2022-2602/.
[38] CVE-2022-2602 Detailed Analysis of Kernel Privilege Escalation [EB/OL]. (2022-10)[2026-05-15]. https://idocdown.com/app/articles/blogs/detail/15354.
[39] oss-security. CVE-2022-4378 disclosure[EB/OL]. (2022-Q4)[2026-05-15]. https://seclists.org/oss-sec/2022/q4/178.
[40] ZENG K. CVE-2022-4378 Original Report [EB/OL]. (2022-12-09)[2026-05-15]. https://www.openwall.com/lists/oss-security/2022/12/09/1.
[41] Google Security Research. CVE-2023-31436 PoC and vulnerability documentation[EB/OL]. (2023-05)[2026-05-15]. https://github.com/google/security-research/blob/master/pocs/linux/kernelctf/CVE-2023-31436_mitigation/docs/vulnerability.md.
[42] CVE-2023-31436 Vulnerability Analysis (Chinese) [EB/OL]. (2023-05)[2026-05-15]. https://idocdown.com/app/articles/blogs/detail/8187.
[43] THE REGISTER. Dirty Frag gets a sequel as Fragnesia hands Linux attackers root-level access [EB/OL]. (2026-05-14)[2026-05-15]. https://www.theregister.com/security/2026/05/14/dirty-frag-gets-a-sequel-as-fragnesia-hands-linux-attackers-root-level-access/5240270.
[44] THEORI. Copy Fail: 732 Bytes to Root on Every Major Linux Distribution [EB/OL]. (2026-04-29)[2026-05-15]. https://xint.io/blog/copy-fail-linux-distributions.
[45] National Vulnerability Database. CVE-2026-31431 [EB/OL]. (2026-04-22)[2026-05-15]. https://nvd.nist.gov/vuln/detail/CVE-2026-31431.
[46] AI JOURNAL. Theori Wins $1.5 Million Prize at DARPA’s AI Cyber Challenge [EB/OL]. (2025-08-11)[2026-05-15]. https://aijourn.com/theori-wins-1-5-million-prize-at-darpas-ai-cyber-challenge/.
[47] Linux Kernel Organization. splice(2) – Linux manual page[EB/OL]. (2025-09-20)[2026-05-15]. https://man7.org/linux/man-pages/man2/splice.2.html.