Written by 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), which dropped at the time of publishing this article, and is the same bug class as Dirty Frag. resource links attached at the end

Index

|---- What Happened
| |---- Copy Fail, CVE-2026-31431
| | |---- Copy Fail Plain English
| | |---- Copy Fail Technical Explanation
| | └---- Copy Fail Disclosure
| |---- Dirty Frag, CVE-2026-43284 + CVE-2026-43500
| | |---- Dirty Frag Plain English
| | |---- Dirty Frag Technical Explanation
| | └---- Dirty Frag Disclosure
| └---- io_uring ZCRX Freelist OOB Write, CVE-2026-43121
| |---- io_uring ZCRX Freelist OOB Write Plain English
| |---- io_uring ZCRX Freelist OOB Write Technical Explanation
| └---- io_uring ZCRX Freelist OOB Write Disclosure
|---- Embargo and Disclosure Etiquette in the Age of LLMs
| |---- What's an Embargo
| └---- Soo Are We Just Skipping Embargoes Now?
|---- Impact and Practical Exploitation Scenarios
| |---- Copy Fail Practical Exploitation Scenario
| |---- Dirty Frag Practical Exploitation Scenario
| └---- io_uring ZCRX Freelist OOB Write Practical Exploitation Scenario
|---- Ok Now I'm Scared, What Do We Do?
| |---- Immediate Fire-Fighting
| | |---- Apply Recommended Mitigations With Caution
| | | |---- Dirty Frag Mitigations
| | | |---- Copy Fail Mitigations
| | | └---- io_uring ZCRX Freelist OOB Write Mitigations
| | └---- This is Not a Time to Try New Things
| └---- Next Steps: House Security Hygiene and Disaster Response
| |---- Revisit Incident Response and Disaster Processes
| |---- Regular Audits of Important Stuff
| └---- Stay Alert and be Prepared
|---- #hugops is for Everyone (Yes that Includes You)
└---- Further Resources

What Happened

Copy Fail, 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, 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. Active in-wild exploitation confirmed

Copy Fail Disclosure

  • Discovered by Theori / Xint via AI-assisted scan of linux/crypto/ ( Xint write-up) 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 + CVE-2026-43500

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, Dirty COW, OverlayFS PE, Dirty Cred)

Dirty Frag Technical Explanation

  • esp_input and the RxKAD verify path both receive splice()-originated skbs 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,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), 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
  • 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,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 was merged and backported to stable before any public blog post
  • 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 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, thealgif_aead submodule for Copy Fail)
    • There is community sentiment 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'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 (upstream, Red Hat) or KernelCare (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/)

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

Dirty Frag — CVE-2026-43284 + CVE-2026-43500

io_uring ZCRX OOB Write — CVE-2026-43121

CrackArmor — CVE-2026-23268 through CVE-2026-23411

Fragnesia — CVE-2026-46300 (disclosed today — patch not yet in stable)

Lineage and Context

Operational and Patching