Linux Compromises, Broken Embargoes, and the Shrinking Patch Window

# Linux Compromises, Broken Embargoes, and the Shrinking Patch Window — AskBaize Source: [https://www.askbaize.com/blog/linux-compromises-broken-embargoes-and-the-shrinking-patch-window](https://www.askbaize.com/blog/linux-compromises-broken-embargoes-and-the-shrinking-patch-window) *Written by*[*Ti Zhang*](https://www.linkedin.com/in/ti-zhang/)*20260503* May 2026 brought three serious Linux local privilege escalation issues in two weeks\. They differ in subsystem and exploit requirements, but share similar patterns\. This article covers what happened, why the disclosure model broke down, what it means for production environments, and what defenders can do now\. Explanations are written for technical audiences with plain english sections to supplement community understanding\. *note: not covered \- Fragnesia \(CVE\-2026\-46300, ID assigned at the moment but*[*not yet populated on NVD*](https://nvd.nist.gov/vuln/detail/CVE-2026-46300%5D)*\), which dropped at the time of publishing this article, and is the same bug class as Dirty Frag\. resource links attached at the end* ## What Happened ### Copy Fail,[CVE\-2026\-31431](https://nvd.nist.gov/vuln/detail/CVE-2026-31431) #### Copy Fail Plain English - A Linux kernel memory\-management bug involving copy\-on\-write \(COW\) behaviour - Programs store memory in pages \(a contiguous block of memory\)\. Although each program is guaranteed its own private pages to save space, the OS will not make a copy if more than one program READS the same page\. - As soon as a second program tries to write or change the page, however, the kernel is supposed to make a copy\(this is the copy\-on\-write\), and Copy Fail broke that guarantee under certain conditions\. Data that should have stayed isolated could be modified unexpectedly - Here's an analogy to help understand: imagine multiple companies sharing a single, strictly read\-only source\-of\-truth rulebook to save space\. A worker needs a page translated into secret code\. Normally, the system makes a private photocopy first\. But due to a flawed efficiency update, the system decides to save paper by writing the translation directly over the original text in the master rulebook\. By skipping the copy step to save resources, the system accidentally lets one worker permanently overwrite the rules for everyone, completely breaking memory isolation\. - Why is this scary?- Isolation failures inside the kernel are dangerous because many security boundaries depend on them, and bugs in memory ownership logic can become privilege\-escalation primitives - Exploitation was more realistic than many race\-condition bugs because it was logic\-related rather than timing\-sensitive - Attackers really go brrr when they can write where you're not supposed to write #### Copy Fail Technical Explanation - Logic flaw in`algif\_aead`— the 2017 in\-place AEAD optimization sets`req\-\>src = req\-\>dst`, allowing`splice\(\)`\-backed page cache pages to land in the output scatterlist; a 4\-byte scratch write during`authencesn`tag rearrangement lands in the spliced file's cached pages - No race condition, no CAP required, no kernel modules beyond`algif\_aead` - [732\-byte Python PoC](https://xint.io/blog/copy-fail-linux-distributions), confirmed root on Ubuntu 24\.04, RHEL 10\.1, Amazon Linux 2023, SUSE 16 - Affects kernel 4\.14 through 6\.19\.11 / 6\.18\.21 \(regression introduced commit`72548b093ee3`, fixed`fafe0fa2995a`\) - [Added to CISA KEV](https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog)\. Active in\-wild exploitation confirmed #### Copy Fail Disclosure - Discovered by[Theori / Xint](https://xint.io/)via AI\-assisted scan of`linux/crypto/`\([Xint write\-up](https://xint.io/blog/copy-fail-linux-distributions)\) and reported to Linux kernel security team around 5 weeks before public release - Theori controlled the disclosure date, so this was not an embargo break\. They chose to publish April 29, 2026 before all distros had shipped patches - Working exploit: 732\-byte Python script, no compilation, runs on all affected distros unchanged - At time of disclosure Arch Linux, Fedora, and Amazon Linux had patches\. SUSE, Red Hat, and Ubuntu had mitigation guidance only, no patched kernels - Theori noted at disclosure that their scan had surfaced additional high\-severity vulnerabilities in the same kernel area, which remained under private responsible disclosure at the time - Interim mitigation \(algif\_aead disallowlist\) widely deployed across the fleet in the days following --- ### Dirty Frag,[CVE\-2026\-43284](https://nvd.nist.gov/vuln/detail/CVE-2026-43284)\+[CVE\-2026\-43500](https://www.openwall.com/lists/oss-security/2026/05/07/8) #### Dirty Frag Plain English - A Linux kernel page\-cache/memory\-fragment reuse bug - The kernel performs in\-place crypto operations on memory pages it does not own write rights to\. When those pages were originally delivered via`splice\(\)`, they remain live pipe pages still owned by the pipe\. The kernel skips the step that would take a private copy first\. The result is an unintended write landing in the page cache of an attacker\-chosen file- pipe: a kernel\-managed buffer that connects two processes - `splice\(\)`is a syscall that moves data between a pipe and a file descriptor without copying it through userspace - The attacker selects the target by controlling what is spliced where — this is not a write to arbitrary cached data, it is a write into a specific file the attacker targets, including files they only have read access to - Analogy to help understand: imagine an office that reuses paper work orders\. When a new job comes in, the manager hands out a form that is physically still attached to the previous worker's outbox\. When the new worker writes on it, the ink bleeds through automatically to the previous worker's copy\. The attachment was never severed — the shared page reference is the problem, not forgotten erasure\. Leftover ownership becomes an active write channel - Why is this scary?- Page\-cache corruption bugs are extremely valuable for attackers\. They can affect binaries, configs, and protected files the attacker can read but is not supposed to modify - The write is invisible to disk\-integrity tooling\. IMA, dm\-verity, and on\-disk checksums operate on the stored file, not the page cache\. A Dirty\-Frag\-modified binary executes from the corrupted in\-memory cache — the verified copy on disk is never touched - Bugs involving cached file data are often easier to weaponize than heap corruption, because they bypass assumptions about read\-only files without requiring a separate leak primitive or`KASLR defeat`\.- KASLR\(Kernel Address Space Layout Randomization\) randomizes where the kernel loads itself in memory on every boot\. Every function, every variable, every data structure sits at a different address each time\. An attacker who wants to overwrite a specific kernel value needs to know its current address first\. Defeating KASLR means finding a way to read a kernel address from within an unprivileged process - Copy Fail and Dirty Frag are scary because you don't need to know any kernel addresses: your target is a file path \(`/usr/bin/su`,`/etc/passwd`\), not a kernel pointer\. The page cache is indexed by file and offset — both of which you control as an unprivileged user\. No address leak required, no KASLR to defeat, no spray to land correctly\. You pick the file, you pick the byte offset, you write\. That is why this class sits in a different threat tier from ZCRX, where the full exploitation chain stalls precisely because KASLR defeat is a hard unsolved step\. - Historically, this class of bug has produced very practical privilege\-escalation exploits\([Dirty Pipe](https://nvd.nist.gov/vuln/detail/CVE-2022-0847),[Dirty COW](https://nvd.nist.gov/vuln/detail/CVE-2016-5195),[OverlayFS PE](https://nvd.nist.gov/vuln/detail/CVE-2021-3493),[Dirty Cred](https://www.google.com/search?q=https://www.blackhat.com/us-22/briefings/schedule/%23dirtycred-escalating-privilege-in-linux-kernel-27156)\) #### Dirty Frag Technical Explanation - `esp\_input`and the RxKAD verify path both receive`splice\(\)`\-originated`skb`s whose fragment pages are backed by pipe pages the kernel does not own\. Both skip`skb\_cow\_data\(\)`before in\-place crypto, writing into the fragment pages directly and producing an unpermitted write into the page cache of the spliced file - Deterministic logic bug — no race, no spray, no KASLR defeat required, no panic on failure\. Target is a file path and byte offset, both attacker\-controlled\. High reliability - [Single\-binary C PoC](https://github.com/V4bel/dirtyfrag),immediate root on all major distros;`algif\_aead`disallow \(Copy Fail mitigation\) does not block this path- Tested: Ubuntu 24\.04, RHEL 10\.1, Fedora 44, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10 - Post\-run: page cache contaminated —`echo 3 \> /proc/sys/vm/drop\_caches`or reboot required; on\-disk copy untouched, IMA/dm\-verity blind to the modification - **CVE\-2026\-43284**— xfrm ESP input \(`esp\_input`\)- IPv4/IPv6 datagram splice paths omit`SKBFL\_SHARED\_FRAG`on UDP skbs; without this flag set, the ESP fast\-path treats the skb as safe for in\-place decrypt — skipping`skb\_cow\_data\(\)`because it sees no frag\_list and an uncloned skb, without checking whether the fragment pages are pipe\-owned - Decrypts over unowned pipe pages, writing crypto output into the page cache of the spliced file - Requires unprivileged userns; blocked by AppArmor userns restriction on Ubuntu - Introduced:`cac2661c53f3`\(2017\-01\-17, ~9yr exposure\); Patch:`f4c50a4034e6` - NVD refs point to stable backport commits; mainline fix is`f4c50a4034e6` - **CVE\-2026\-43500**— RxRPC / RxKAD verify path- In\-place decrypt over splice\-originated frags without COW; no userns required, lower privilege bar than CVE\-2026\-43284 - `rxrpc\.ko`not loaded by default on most distros; Ubuntu autoloads it, making the RxRPC path the universal fallback where AppArmor blocks the ESP path - Chain logic: ESP path covers non\-Ubuntu \(userns open\); RxRPC path covers Ubuntu \(`rxrpc\.ko`autoloaded, userns irrelevant\) — blind spots cancel, universal LPE - Introduced:`2dc334f1a63a`\(2023\-06\-08, ~3yr exposure\); Patch:`aa54b1d27fe0` - Specific symbol within RxKAD verify path unconfirmed — verify against`aa54b1d27fe0`diff before citing #### Dirty Frag Disclosure - Discovered by[Hyunwoo Kim \(@v4bel\)](https://x.com/v4bel), who reported privately to Linux maintainers April 30, 2026 - Linux distro embargo was set for May 12, but was broken externally before patches or CVEs existed- On May 7, an unrelated third party independently published a working exploit a full explanation on \(oss\-security\)\([https://www\.openwall\.com/lists/oss\-security/2026/05/07/12\)\(\[Write\-up\]\(https://afflicted\.sh/blog/posts/copy\-fail\-2\.html\)and](https://www.openwall.com/lists/oss-security/2026/05/07/12)(%5BWrite-up%5D(https://afflicted.sh/blog/posts/copy-fail-2.html)and)[GitHub PoC](https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo)\) - The working exploit was reverse\-engineered from the fix commit`f4c50a4034e6`publicly available on on`netdev/net\.git` - A second independent PoC[Copy Fail 2: Electric Boogaloo](https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo/tree/main)targeting the same paths posted publicly around the same time\. - `\_SiCk`[clarified on oss\-security](https://www.openwall.com/lists/oss-security/2026/05/07/12): "The work is n\-day weaponization from a public upstream commit, which is standard practice once a security\-relevant fix lands in a public tree" and apologised directly to Hyunwoo Kim - Kim wrote on oss\-security:*"Because the embargo has currently been broken, no patch or CVE exists"*after consulting`linux\-distros@vs\.openwall\.org`\. At maintainers' request, he published his full write\-up and PoC the same day- At time of disclosure there were no patches and no CVEs\. This was materially worse than Copy Fail's disclosure state - CVEs allocated post\-facto\(CVE\-2026\-43284 \(ESP\) and CVE\-2026\-43500 \(RxRPC\) assigned May 8\) - AlmaLinux and Ubuntu shipped patched kernels by May 8; RHEL, SUSE, Debian, Fedora acknowledged with patches in progress --- ### [io\_uring ZCRX freelist OOB write](https://ze3tar.github.io/post-zcrx.html),[CVE\-2026\-43121](https://app.opencve.io/cve/CVE-2026-43121) #### io\_uring ZCRX freelist OOB write Plain English - Bookkeeping failure caused by two CPU cores trying to clean up the same thing at the same time\. The kernel accidentally frees the same object twice and its internal recycling list becomes corrupted\. Eventually the kernel writes data outside the memory region it was supposed to use - That memory corruption could potentially be turned into privilege escalation, though no fully working public exploit chain currently exists\. The vulnerable code is part of`io\_uring`, a high\-performance Linux I/O system used for very fast networking and storage operations\. The specific feature involved is called ZCRX \(“zero\-copy receive”\) - The idea behind zero\-copy systems is to avoid constantly copying data around in memory and reuse existing buffers instead, which improves performance and reduces CPU overhead - This is great for speed but makes memory ownership tracking complicated - Analogy to help understand: rental car company has two clerks\. if someone has finished with a rental car, clerk A checks into system "hey there's a new available car ready to be rented"\(CPU0 sees count=1, frees object\)\. By some mistake clerk B also checks the same car into the system\(CPU1 sees count=1, frees same object\)\. Now the company's system thinks there are \+2 cars available for renting instead of \+1\(kernel now accidentally places same object into reusable\-object list twice\)- That reusable list eventually becomes corrupted because the kernel thinks it has more free objects than it actually does\(the rental car company thinks it has more cars to rent out than it does\)\. Then the kernel writes past the end of an internal array \(an OOB, out\-of\-bounds write\) - Attacker can exploit by placing an place an important kernel object next to the corrupted region, damaging it in a useful way, and gradually turn that into more control \(heap grooming, slab placement, object spraying\)\. You may hear`controlled memory layout manipulation`thrown around when researchers talk about this - This is less scary than Dirty Frag or Copy Fail- Dirty Frag/Copy Fail \(Dirty Pipe family\) are deterministic, easy to trigger reliably, and bypasses KASLR defeat - io\_uring ZCRX freelist OOB \(i feel like i'm summoning a computer demon if i have to type this one more time i'm ordering myself some fizzy sodas with real sugar\) is harder to exploit because it depends on timing, and multiple CPU cores must race in just the right way\. The corruption primitive is weaker, and no complete public root exploit exists as of now\. - The vulnerability requires`CAP\_NET\_ADMIN`, which is a privileged Linux capability for special networking software stuffs\. So if an attacker has`CAP\_NET\_ADMIN`you are already in hot waters - Realistic risk areas include privileged containers, kubernetes workloads with execessive permissions, networking tools, observability agents, service mesh components, etc #### io\_uring ZCRX freelist OOB write Technical Explanation - Different class from Copy Fail and Dirty Frag\(no page\-cache write primitive, no COW bypass, no splice involvement\)\. Not deterministic, requires a timing window on SMP - Less severe than Copy Fail and Dirty Frag - SMP race condition \-\>double\-free \-\> heap OOB write into adjacent slab object - Full exploitation chain \(double\-free \-\> slab corruption \-\> KASLR break \-\>`modprobe\_path`overwrite \-\> uid=0\) undemonstrated publicly at time of writing - `io\_zcrx\_put\_niov\_uref\(\)`implements a non\-atomic check\-then\-decrement on`user\_refs`:`atomic\_read\(\)`followed by a separate`atomic\_dec\(\)`, serialized against other callers via`rq\_lock` - `io\_zcrx\_scrub\(\)`modifies`user\_refs`via`atomic\_xchg\(\)`without holding`rq\_lock` - On SMP, both paths pass the`user\_refs == 1`check concurrently; both call`io\_zcrx\_return\_niov\(\)`on the same`niov`; the same`niov`is pushed to the freelist stack twice \(double\-free\) - `free\_count`\(the stack pointer\) exceeds`nr\_iovs`\(the stack depth\); subsequent freelist push writes a u32 past the end of the`kvmalloc`'d freelist array into the adjacent slab object - The bug is not a missing bounds check on userspace\-supplied`rqe\-\>off`— it is atomicity failure between two kernel teardown paths - Note:`IORING\_REGISTER\_ZCRX\_IFQ`requires`CAP\_NET\_ADMIN`- The ze3tar PoC escalation path as written requires`CAP\_SYS\_ADMIN`\. Jens Axboe on oss\-security:*"If you already have CAP\_SYS\_ADMIN, what is the point?"* - Valid in\-scope workloads: containers with`NET\_ADMIN`in`securityContext`running kernel ≥ 6\.12 without the backport - ZCRX introduced in 6\.12; kernels 5\.15, 6\.1 LTS not affected #### io\_uring ZCRX freelist OOB write Disclosure - Kai Aizen \(`snailsploit\.com`\) found the race, authored the fix, submitted upstream Feb 18, 2026 - Patch[`003049b1c4fb`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=003049b1c4fb8aabb93febb7d1e49004f6ad653b)was merged and backported to stable before any public blog post - [CVE\-2026\-43121](https://app.opencve.io/cve/CVE-2026-43121), published May 6, 2026 - CVE request Filed on oss\-security by Mohamed Salem Eddah\. Solar Designer flagged it as likely AI\-generated, original finder \(Aizen\) was not the requester - ze3tar blog\. Published post\-patch with PoC; Solar Designer and Axboe reviewed the exploit code on\-list and called it AI slop; ze3tar acknowledged on[oss\-security](https://seclists.org/oss-sec/2026/q2/444)the bug was already fixed and the escalation path was incomplete - No embargo was involved: Aizen submitted a patch through normal kernel development, not a private linux\-distros report;`003049b1c4fb`was public the moment it merged, making the fix commit itself the de facto public disclosure - Mohamed's CVE request and ze3tar's blog are both downstream of that public commit, not of any private disclosure\. This was the same mechanism that broke Dirty Frag's embargo, except here no embargo existed to break because the fix was in place - Process was arguably cleaner than coordinated disclosure: patch reached users before public exploitation analysis followed\. The dysfunction was limited to Mohamed filing a CVE for a bug he didn't find and ze3tar overstating exploitation status, neither affected the patch timeline or user exposure window- Arguably, the real crime with io\_uring ZCRX freelist OOB write\(i am sooo done\) was how the CVE was published around the same time as Dirty Frag and Copy Fail, and appeared on first look as something of the same seriousness due to the way it is written\. When everything seems urgent and scary, nothing is \(RIP to everyone's blood pressure\) ## Embargo and Disclosure Etiquette in the age of LLMs ### What's an Embargo An embargo is a coordination norm\. It is not an NDA, and not enforceable against the entire internet\. It's really a code of honour, plain to speak, a bunch of people in an exclusive group going "ok you won't tell and i won't tell, but here's what we are going to do, and here's when we will do it"\. Embargoes break when - A fix lands publicly before patches are broadly available - Someone outside the list independently finds the bug from a public commit - The bug class is obvious from the diff - The cost of staying quiet exceeds the benefit The CVEs we have discussed so far are not the only recent discoveries to have had a non\-typical disclosure process\. CrackArmor \(disclosed March 12, 2026 by Qualis TRU, patches CVE\-2026\-23268 through CVE\-2026\-23411, March 19 to April 1\) CrackArmor enables unprivileged users to create fully\-capable user namespaces, effectively getting around Ubuntu's user namespace restrictions implemented via AppArmor\. The vulnerabilities were shared with Canonical back in July 2025, but did not have CVEs assigned at the time of disclosure\. Qualys noted "communication delays" and sent follow\-ups to Ubuntu's security team and Canonical's AppArmor developers in December 2025 and January 2026\. ### Soo Are We Just Skipping Embargoes Now? Before we had LLMs, we could count on some assumptions: - Bugs stayed private until patches were ready - Attackers needed meaningful time to weaponize published details - Distros could ship before exploitation became widespread These assumptions are not as reliable now\. LLMs make reverse\-engineering more accessible\. AI is incredibly bad at writing reliable secure code, but AI is very very good at poking holes and finding vulnerabilities\. This lands the industry in a bad situation: AI go brrr at helping developing exploits for skilled attackers, but AI go less brrr for helping with developing patches \(and not all patches are written with AI assistance\)\. Patch authorship isn't the bottleneck here, what's slow is everything after: validation, backporting across kernel versions, regression testing, distro integration, and shipping\. That pipeline moves at human\-organizational speed regardless of LLM capability, and attackers with motivation and a public fix commit don't have to wait for any of it\. Response is slower than attackers with motivation and it's not because people aren't smart enough, it's just the way it is in an LLM\-powered security landscape\. Closing the gap between mitigation and attack means boring reliable work and keeping your house clean, we all panic less when we have mitigations in place and prepare for disasters ahead of time: - Know your kernel exposure - Restrict unprivileged user namespaces on hosts that do not need them - Patch faster where it matters; build the process before you need it - Reduce dangerous capabilities at the workload level - Block unused kernel surfaces — modules, syscalls, io\_uring - Watch sensitive subsystem commits directly - Detect behavior, not CVE names - Keep an IPsec dependency map current and tested Open development and coordinated embargoes do not always work the way we want\. A public fix commit is a public disclosure, whether anyone intends it to be or not\. Kernel maintainers and researchers are working under real constraints\. The process failures here were largely structural, not individual\. Let's have empathy for that is warranted\. ## Impact and Practical Exploitation Scenarios These discoveries are host\-kernel territory\. Container namespaces do not protect you from a vulnerable host kernel\. Containers share the host kernel — a page\-cache write from inside a container lands in the host's page cache, affecting every process on the host reading the same file, including processes outside the container entirely\. Namespace isolation is filesystem and process namespace isolation; it does not isolate the page cache\. If an unprivileged process inside a container can reach the vulnerable path, the result is host root\. Impacted environments include but are not limited to multi\-tenant Kubernetes nodes, CI runners, build farms, shared developer platforms, and any environment running arbitrary workloads\. Dirty Frag mitigations also have real operational cost: - Blocking`esp4`and`esp6`breaks kernel\-space IPsec — strongSwan, Libreswan, and any stack using the kernel ESP data plane cannot safely apply this - Blocking`rxrpc`mainly affects AFS clients and is safe to apply on almost everything else - VPN providers running IKEv2/IPsec with kernel ESP have no viable interim mitigation that preserves service — the module blacklist is the data plane\. The only fix is the kernel patch\. WireGuard is not affected; it does not use the xfrm/ESP path *Addendum Post Publish: Fragnesia \(CVE\-2026\-46300\) is a pre\-existing latent bug in the same surface area that became practically exploitable as a consequence of the Dirty Frag patch — the fix changed kernel behavior in a way that exposed it\. The mitigation is identical: esp4, esp6, rxrpc blacklist\. The kernel patch is on netdev awaiting merge; no stable backport exists as of May 13, 2026\.* ### Copy Fail Practical Exploitation Scenario *Abstract Scenario* - An unprivileged user opens a readable setuid binary and splices it into an AF\_ALG socket - The`algif\_aead`in\-place optimization leaves the page cache pages shared with the splice pipe - A 4\-byte scratch write during`authencesn`tag rearrangement\(internal crypto buffer rearrangement step\) lands in the page cache of the spliced file at an attacker\-influenced offset - The in\-memory copy of the binary is now modified without any write permission to the file, without touching disk, and without invalidating IMA measurements or dm\-verity - Result: next execution of that binary runs the attacker's modified version as root *I Heard People Like Stories* - A developer has a shell account on a shared Linux build server running an unpatched kernel - They write a 732\-byte Python script, no compilation required, and run it as their normal unprivileged user - The script splices`/usr/bin/su`into an AF\_ALG socket and triggers the scratch write at a controlled offset - The in\-memory copy of`su`is silently patched, a subsequent execution of`su`could execute attacker\-modified page\-cache contents - Result: root on the build server, access to signing keys, source repositories, and any credentials cached on that host --- ### Dirty Frag Practical Exploitation Scenario *Abstract Scenario* - An attacker splices a target file into a network socket path that performs in\-place crypto - The kernel skips`skb\_cow\_data\(\)`— the skb's fragment pages are pipe pages still referencing the file's page cache- The written value is the decrypted crypto output, which is attacker\-influenced but not arbitrary\. This is sufficient to corrupt branch instructions, function pointers, or auth logic in the target binary - What the attacker can influence is the targeted file and write offset — no KASLR defeat, no spray required - In\-place decrypt writes crypto output directly into the page cache of the spliced file - Result: in\-memory modification of an attacker\-chosen file including setuid binaries, auth helpers, or runtime configs; on\-disk copy and integrity tooling untouched *I Heard People Like Stories* - A CI/CD runner executes untrusted pull request builds in low\-privilege containers on shared Ubuntu workers - A malicious contributor submits a build script that triggers the RxRPC path - The script abuses the kernel networking path to modify the cached pages of`/usr/bin/sudo`\. The modified binary is now live in memory across the entire host, while the on\-disk copy passes all integrity checks- shared page cache means every process on the host reading`/usr/bin/sudo`hits the same corrupted pages - Result: next`sudo`invocation on the worker executes the attacker's payload, exposing deployment credentials, secrets, and neighbouring workloads --- ### io\_uring ZCRX Freelist OOB Write — Practical Exploitation Scenario *Abstract Scenario* - A privileged \(likely networking\) process with`CAP\_NET\_ADMIN`registers a ZCRX interface queue and repeatedly triggers the scrub/refill race - `free\_count`exceeds`nr\_iovs`; a u32 is written past the end of the freelist array into an adjacent slab object - The attacker controls slab cache placement via area size at registration, then fills that cache with a target object type via object spray to ensure the OOB write lands predictably - Full chain requires KASLR defeat via a separate read primitive\(so far undemonstrated publicly\) - Result if chain completes: container escape, root on host \(but this has a lot of prerequisites\) *I Heard People Like Stories* - A Kubernetes cluster grants`NET\_ADMIN`to networking sidecars on a ≥6\.12 kernel with ZCRX enabled - An attacker compromises a sidecar container through an unrelated application\-layer vulnerability such as an RCE in a sidecar proxy or service mesh component - From inside the sidecar they repeatedly trigger the ZCRX race, grooming heap layout until the overwrite corrupts a target kernel object - Each step of the chain\(spray landing correctly, KASLR break, controlled overwrite of a useful target\) has independent failure modes\. At this point no public PoC completes this - Result if successful \(i\.e\. process has CAP\_NET\_ADMIN and KASLR defeat is achieved\): root on the Kubernetes worker node, access to service account tokens, secrets, and neighboring tenant workloads ## Ok Now I'm Scared, What Do We Do? ### Immediate Fire\-Fighting #### Apply Recommended Mitigations With Caution Applicable to all three of these, immediately carry out some house security hygiene: - Restrict unprivileged user namespaces - Track kernel update closely - Audit`CAP\_NET\_ADMIN` Carry out below mitigations independently as they do not cover each other's blast area\. ##### Dirty Frag Mitigations - `rxrpc`is safe to block on almost everything that is not an AFS client - Recommended Dirty Frag mitigations \(disabling`esp4`and`esp6`\)affect IPsec , and hosts terminating IPsec tunnels cannot safely apply this- on those hosts a safe interim option is network\-layer access control: restrict who can reach the host locally, audit userns policy, and treat kernel patch as the only real fix\. The module blacklist is not an option - VPN infrastructure running kernel\-space IPsec \(IKEv2/IPsec via strongSwan or Libreswan with kernel ESP\) cannot safely apply the esp4/esp6 module blacklist — that is the data plane\. The only viable fix is the kernel patch\. Providers on distro kernels without the Dirty Frag or Fragnesia backport yet have no interim mitigation that preserves service\. Multi\-tenant VPN concentrators should treat this as elevated urgency and track distro patch availability directly rather than waiting for routine update cycles\. Wireguard not affected\. - Investigate workloads repeatedly trying to load`esp4`,`esp6`, or`rxrpc`after disallowlisting\. Keep an eye out in your logs for failed autoloads due to`/bin/false`overrides will appear, and treat unexpected attempts as suspicious ##### Copy Fail Mitigations - Some nuances on AF\_ALG related mitigations \(specifically, the`algif\_aead submodule`for Copy Fail\)- There is[community sentiment](https://news.ycombinator.com/item?id=47956312)around the frequent AF\_ALG\(`algif\_aead`is a submodule of AF\_ALG\) exploits\. For most workloads, userspace crypto libraries \(OpenSSL, GnuTLS, wolfSSL\) are sufficient\. They implement AEAD primitives directly using AES\-NI, VAES, and ARMv8 crypto extensions without needing kernel boundary crossing\. On bulk symmetric crypto, userspace often wins on throughput by eliminating syscall overhead \(this applies less for workloads already using`io\_uring`with AF\_ALG, because`io\_uring`\-based AF\_ALG removes most of the syscall overhead on modern kernels\) - It is not always the case, so you may want to disallow`algif\_aead`first\.`algif\_hash`and`algif\_skcipher`have different usage profiles and a cleaner exploit history — a blanket AF\_ALG disable may be overkill for most environments\.\*\*\*\* - To minimize breaking changes, check these:- FIPS 140 — the kernel FIPS module covers AF\_ALG consumers\. Userspace replacement needs its own validated implementation\. OpenSSL has it; not every stack does\. - PCIe crypto offload — Intel QAT and some SmartNIC offload paths are only reachable through the kernel crypto API\. AES\-NI is CPU\-local and does not substitute for attached hardware accelerators that register as kernel crypto drivers\. - `cryptsetup`/`dm\-crypt`— AF\_ALG is used in specific disk encryption configurations opportunistically, but falls back to userspace libgcrypt/OpenSSL if AF\_ALG is unavailable\. Audit before disabling just to be doubly careful ##### io\_uring ZCRX freelist OOB mitigations - ZCRX is ≥6\.12 only, hosts on 5\.15, 6\.1 LTS are not in scope, verify your kernel version before treating this as applicable\. Patch`003049b1c4fb`is in stable and backported to all maintained branches, just apply\. - No module blacklist equivalent exists for ZCRX —`io\_uring`itself cannot be blacklisted on workloads that depend on it, and ZCRX is a feature within io\_uring rather than a separable module- If io\_uring is not required by any workload on the host, syscall restriction via seccomp is a viable surface reduction: block`io\_uring\_setup`entirely - The only scenario where the io\_uring/seccomp restriction is worth considering is a host running a vulnerable kernel where patching is blocked for some reason \(frozen image, vendor lock, compliance hold\), still verify for dependencies to prevent silent failures - `NET\_ADMIN`in container`securityContext`should be treated as a high\-trust grant in general\. Always evaluate specific capability is actually required or whether a more scoped alternative exists - Since the full exploitation path has not been demonstrated, the patch urgency is real but operational risk is lower than Copy Fail or Dirty Frag #### This is Not a Time to Try New Things I said this to my partner and they were like "saying this in the year of our lord AI is pretty funny"\. Head nod to friend[Xe](https://xeiaso.net/blog/2026/abstain-from-install/)'s advice for not installing new software\. If you must you must, just know this is a very bad time\. I kind of feel like the security landscape right now is akin to a club with very dirty bathooms and people who don't wash their hands, we really don't know what's going on anymore\. ### Next Steps: House Security Hygiene and Disaster Response Having spoken to ~20 friends and clients in the industry over the last few weeks, I have observed significantly less stress from teams who have in\-place house hygiene and environment hardening practices\. This is not to say those who don't are not as good as engineering, many factors contribute to technical debt, and teams need to be well\-resourced with support and strategy from organization leadership to combat complex system entropy\. If your team is able to, consider these structural fixes and audits\. If your team needs more support in order to devote more engineering resources to this type of work \(which can often be seen as cost centre work and not worth doing\), show sections of this article to folks who can help you shift work priorities\. In our current security landscape, companies who devote appropriate investments to security and system reliability ultimately win out in margins \(incidents are expensive, as is losing customers\)\. #### Revisit Incident Response and Disaster Processes As we've discussed in the embargoes section, we may need to patch faster as public LPEs with working exploits are becoming frequent\. For multi\-tenant hosts, CI runners, and shared compute, you need a faster path\. As is the case for all disaster responses, preparation ahead of time is key\. Responding and not reacting will keep us ahead of the curve when it comes to defense\. - Review and update your emergency reboot process for kernel CVEs - Livepatching where reboots are painful\. Note that livepatch coverage for a given CVE is not guaranteed and varies by vendor and kernel version\.[kpatch](https://github.com/dynup/kpatch)\(upstream, Red Hat\) or[KernelCare](https://tuxcare.com/live-patching-services/)\(TuxCare commercial\) both have coverage lag for novel bug classes\. For Copy Fail and Dirty Frag specifically, verify coverage before treating livepatch as equivalent to a full kernel update\. - Keep node pools where possible for faster cycling - Review change\-making and breakclass processes for active KEV\-listed CVEs to speed up incident response #### Regular Audits of Important Stuff - Make seccomp profile validation part of your ritualistic audit\. Go beyond policy document review, test against actual syscall behavior at runtime using tools like`seccomp\-tools`or`tracee`\. Policy documents frequently drift from what containers actually do\. - Restrict unprivileged usernamespaces on server and CI hosts where userns\-dependent tooling \(eg Podman rootless, chrome sandboxing, etc\) are not present\. Evaluate before pusehing broadly - Regularly audit powerful capabilities like`CAP\_NET\_ADMIN`, confirm uses are necessary and remove where possible - Review container configurations for best security practices \(eg[https://kubernetes\.io/docs/tasks/configure\-pod\-container/security\-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)\) Know your Reachability and maintain SBOM/dependency hygiene for kernel consumers: - several mitigations \(IPsec mapping, CAP\_NET\_ADMIN audit, io\_uring dependency check\) require knowing what your workloads actually use\. Teams without current SBOMs and capability manifests cannot answer these questions quickly under incident pressure - A standing audit of capability grants and kernel feature dependencies belongs in the hygiene section as a prerequisite to effective incident response- Concrete instance: Map IPsec dependencies, because the next incident is a`when`not`if`\. Be prepared by knowing, have these documented and tested before the next 2AM page:- Which hosts terminate IPsec tunnels - Which use kernel\-space \(esp4/esp6\) vs\. userspace \(libreswan with netlink, strongSwan with user\-space crypto\) paths - What breaks if`esp4`and`esp6`are blacklisted on each host class - Who owns the fallback and what the recovery time looks like #### Stay Alert and be Prepared As is with any system, observability and preparedness will keep you ahead of the game\. - watch kernel commits directly\. Distro advisories are downstream\. Security teams that monitor sensitive kernel areas have hours of lead time over teams waiting for packaged advisories- Rough commit flagging on these paths\(even just a daily grep of git logs\)is better than waiting for a polished advisory - Generic kernel monitoring could be too broad to be actionable\. Watching`netdev/net\.git`,`crypto/`,`io\_uring/`,`security/`\(AppArmor/LSM\) would have caught the issues mentioned in this article - Consider automating this type of alerting - behaviour\-based detection and alerting- eBPF infrastructure is a natural fit for kernel compromises, but having the tooling set up does not automatically mean useful detection logic\. here's a short list of what to alert on relevant to this article- unexpected`splice\(\)`into AF\_ALG or RxRPC sockets from non\-root processes - `setuid`binary execution immediately following`splice\(\)`calls in the same process lineage - `io\_uring\_register`with`IORING\_REGISTER\_ZCRX\_IFQ`from containerized processes - page cache invalidation \(`drop\_caches`\) outside of scheduled maintenance windows - We live in the world of AI\-driven observability and there is a call for automating SREs out of the step, but teams are better off having human intervention when it comes to determining what to observe and alert on, and who to page\. Remember, AI is not sentient, and we need neuroplasticity and real consciousness involved for useful decision\-making to defend against sophisticated attackers ## \#hugops is for Everyone \(Yes that Includes You\) People who always want to do a good job and be the best versions of themselves hold beliefs that sound something like "if we do our best, then nothing bad could happen"\. Yet life is a series of stochastic events following vague patterns that do not serve as valid prediction heuristics\. If you are tearing your hair out over "why is this happening to me/us/the industry" and "why are they like this"/"why AM I like this", remember bad things can happen to good people, compromises can happen to well\-loved systems, and harm can be done by well\-meaning folks\. A little empathy goes a long way, and we do our best work when we are at peace with ourselves and the world\. Many of the issues we are observing \(both long\-standing and new\) can only be solved by us as a community\. Regardless of whether you are a believer of "move fast and make mistakes" or "move with intention and bias towards caution", remember \#hugops is for everyone, that includes you and everyone who works and does not work like you\. The industry is big enough to accommodate many different ways of work, technical rigour is not the only thing we need, continuous optimization driven by diversity of thought will get us through the next phase of software development evolution\. ## Further Resources **Copy Fail — CVE\-2026\-31431** - [copy\.fail](https://copy.fail/) - [Xint/Theori write\-up](https://xint.io/blog/copy-fail-linux-distributions) - [NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-31431) - [CISA KEV entry](https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog) - [Canonical advisory](https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available) - [oss\-security original disclosure](https://www.openwall.com/lists/oss-security/2026/04/29/23) - [Mainline fix — a664bf3d603d](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5) - [Microsoft Defender advisory](https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/) - [CloudLinux — modprobe blacklist caveat on RHEL\-family](https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update) **Dirty Frag — CVE\-2026\-43284 \+ CVE\-2026\-43500** - [github\.com/V4bel/dirtyfrag](https://github.com/V4bel/dirtyfrag) - [NVD — CVE\-2026\-43284](https://nvd.nist.gov/vuln/detail/CVE-2026-43284) - [oss\-security — Kim's disclosure](https://www.openwall.com/lists/oss-security/2026/05/07/8) - [oss\-security — \_SiCk / Copy Fail 2 Electric Boogaloo](https://www.openwall.com/lists/oss-security/2026/05/07/12) - [Copy Fail 2: Electric Boogaloo PoC](https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo) - [afflicted\.sh write\-up](https://afflicted.sh/blog/posts/copy-fail-2.html) - [Canonical advisory](https://canonical.com/blog/dirty-frag-linux-vulnerability-fixes-available) - [Wiz research](https://www.wiz.io/blog/dirty-frag-linux-kernel-local-privilege-escalation-via-esp-and-rxrpc) - [Qualys analysis](https://blog.qualys.com/product-tech/vulnmgmt-detection-response/2026/05/09/dirty-frag-using-the-page-caches-as-an-attack-surface) - [AKS advisory and mitigation DaemonSet](https://github.com/Azure/AKS/issues/5753) - [Mainline patch — f4c50a4034e6 \(ESP\)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4) - [Mainline patch — aa54b1d27fe0 \(RxRPC\)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71) **io\_uring ZCRX OOB Write — CVE\-2026\-43121** - [NVD — CVE\-2026\-43121](https://app.opencve.io/cve/CVE-2026-43121) - [Kai Aizen original research](https://snailsploit.com/security-research/general/io-uring-zcrx-race-condition/) - [oss\-security CVE request thread \+ Solar Designer / Axboe review](https://seclists.org/oss-sec/2026/q2/444) - [Mainline patch — 003049b1c4fb](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=003049b1c4fb8aabb93febb7d1e49004f6ad653b) **CrackArmor — CVE\-2026\-23268 through CVE\-2026\-23411** - [Qualys TRU advisory](https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root) - [Canonical vulnerability knowledge base](https://ubuntu.com/security/vulnerabilities/crackarmor) - [Canonical advisory](https://canonical.com/blog/apparmor-vulnerability-fixes-available) **Fragnesia — CVE\-2026\-46300***\(disclosed today — patch not yet in stable\)* - [V12 Security PoC](https://github.com/v12-security/pocs/tree/main/fragnesia) - [oss\-security disclosure](https://seclists.org/oss-sec/2026/q2/517) - [Netdev patch](https://lore.kernel.org/all/[email protected]/) - [AlmaLinux advisory](https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/) - [TuxCare/KernelCare advisory](https://tuxcare.com/blog/fragnesia-cve-2026-46300-is-a-new-linux-kernel-lpe/) **Lineage and Context** - [Dirty Pipe — CVE\-2022\-0847](https://dirtypipe.cm4all.com/) - [Dirty COW — CVE\-2016\-5195](https://nvd.nist.gov/vuln/detail/CVE-2016-5195) - [Dirty Cred — Black Hat 2022](https://www.blackhat.com/us-22/briefings/schedule/#dirtycred-escalating-privilege-in-linux-kernel-27156) - [Mini Shai Hulud / TanStack supply chain compromise](https://www.aikido.dev/blog/mini-shai-hulud-is-back-tanstack-compromised) **Operational and Patching** - [kpatch — upstream livepatch](https://github.com/dynup/kpatch) - [KernelCare — TuxCare commercial livepatch](https://tuxcare.com/live-patching-services/) - [Kubernetes securityContext reference](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [CERT\-EU Copy Fail advisory — AF\_ALG exposure check:`lsof \| grep AF\_ALG`](https://cert.europa.eu/publications/security-advisories/2026-005/)