Dirty Frag (CVE-2026-43284, CVE-2026-43500): how the same page-cache write class that powered Copy Fail came back in IPSec and rxrpc, and leaked before the patch was ready

One week after Copy Fail (CVE-2026-31431) began setting the Linux server world on fire, researcher Hyunwoo Kim published a second vulnerability in the same broad class. Dirty Frag chains two separate Linux kernel flaws, CVE-2026-43284 and CVE-2026-43500, to achieve reliable local privilege escalation to root on virtually every Linux distribution shipped since 2017. A working public proof-of-concept exists. A single C binary, compiled from the public repository and run without arguments, drops a root shell. The entire operation is deterministic, requires no race condition, and leaves no trace in standard audit logs.

What makes this disclosure particularly uncomfortable is that it was not planned. Kim reported both flaws to the kernel security team on April 29-30, submitted patches to the netdev mailing list, and set a five-day embargo with Linux distributions on May 7. An unrelated third party broke that embargo the same day, publishing the full exploit before distributions had finished building patched kernels. As of May 8, 2026, the upstream patch for the RxRPC component (CVE-2026-43500) has not been merged into the mainline kernel. Distribution patches are rolling out now, but the exploit is already public.

Canonical assesses the CVSS 3.1 score at 7.8 (High) for both CVEs. The exploitation requires local access, which keeps the score from reaching critical. What it does not capture is the reliability and ubiquity: any user who can open a shell on an affected Linux system, including SSH sessions, container shells with host kernel access, and cloud instance logins, can become root in under two seconds.

This article follows the same two-part format we use for all our CVE breakdowns: a plain-language executive summary first, then a full technical dissection for readers who want to understand both vulnerabilities and the chaining logic from first principles. At the end, we discuss what this class of vulnerability means for teams running Linux workloads at scale, and how the Pragma Core platform addresses the underlying detection and prevention challenges.

Part I. Executive breakdown

What happened

Hyunwoo Kim, posting as @v4bel, identified two new instances of the page-cache write primitive that underpins the Dirty Pipe and Copy Fail vulnerability families. Both new instances use the same core technique: splice() plants a reference to a page cache page that the attacker only has read access to into the fragment slot of a socket buffer, and the kernel's in-place cryptographic processing writes to that fragment, thereby writing to the page cache without going through any permission check.

The first instance (CVE-2026-43284) lives in the xfrm IPSec ESP processing path (esp4/esp6 modules). It provides a powerful primitive: four arbitrary bytes can be written to any file offset the attacker chooses. This variant requires the ability to create a user namespace, which is a standard feature on most Linux distributions but may be restricted by AppArmor on some Ubuntu configurations.

The second instance (CVE-2026-43500) lives in the RxRPC protocol implementation (rxrpc module). It does not require namespace creation privileges, making it exploitable by any unprivileged user without any additional capabilities. The value written is eight bytes whose content depends on a cipher function, which the attacker brute-forces in userspace. The rxrpc module is not shipped by default on all distributions, but it is included on Ubuntu.

The two variants are chained in a single exploit binary. The binary tries the ESP variant first. If it is blocked (namespace creation disabled or esp4/esp6 not loaded), it falls back to the RxRPC variant. The combination covers the blind spots of each individual variant and produces a single exploit that works across all major distributions.

A critical operational detail: applying the Copy Fail mitigation (blacklisting algif_aead) does not protect against Dirty Frag. The two vulnerability families use different modules and different code paths. A system that has been fully mitigated against Copy Fail remains fully exploitable via Dirty Frag.

Who is affected

The xfrm-ESP vulnerability (CVE-2026-43284) is present in every kernel since January 2017 (commit cac2661c53f3). The RxRPC vulnerability (CVE-2026-43500) was introduced in June 2023 (commit 2dc334f1a63a). Together, the effective lifetime of the vulnerability class is approximately nine years.

Why this matters more in cloud and Kubernetes environments

Dirty Frag is a local privilege escalation. Its practical impact expands significantly in multi-tenant and cloud environments, for the same reasons Copy Fail did.

The page cache is a host-level resource. A process running inside a container shares the host kernel's page cache, not an isolated copy. Writing to the page cache of /etc/passwd or /usr/bin/su from inside a container modifies the same in-memory copy that the host kernel and all other containers on the same node use. A container with any degree of file-read access to host files can use Dirty Frag to corrupt those files in RAM without any host-level write permission.

In cloud instances and shared hosting environments, every user who has SSH access or a web shell into a shared Linux environment has a path to root. This applies to hosted development environments, CI/CD workers running shared kernel nodes, and any multi-tenant system where users execute code under different UIDs on the same kernel.

In Kubernetes, the immediate concern is node compromise. A pod with a compromised application process can use Dirty Frag to escalate to root on the node, then access node-level secrets, kubelet credentials, or other pods' data on the same node. Namespace isolation and RBAC policies do not protect against a kernel-level write primitive that bypasses all file system permissions.

The secondary concern is remediation mechanics. Unlike a standard package vulnerability, a kernel update requires a node reboot or a live patch. In large clusters, coordinating rolling reboots while maintaining service availability takes time, and every node that has not been rebooted or live-patched remains exploitable by any user with shell access.

Recommended actions

1. Apply the interim mitigation immediately. Blacklist the three affected modules with a single command. This blocks both CVE-2026-43284 and CVE-2026-43500 until patched kernels are available:

   sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
   

   The three modules (esp4, esp6, rxrpc) relate to IPSec ESP and the AFS RxRPC protocol. They are not loaded on servers that do not run IPSec or AFS. Verify the impact of blacklisting in your environment before applying on production nodes, but on the vast majority of servers this command has no operational effect.

2. Apply patched kernels as they become available and reboot. Patched kernel packages are rolling out to major distributions now. After installation, the module blacklist should be reversed (remove /etc/modprobe.d/dirtyfrag.conf). Check your distribution's security advisory for the specific patched package version.

3. Do not rely on the Copy Fail mitigation as protection against Dirty Frag. If your current security posture treats the algif_aead blacklist as sufficient coverage for this class of bug, it is not. Dirty Frag uses different modules and is not blocked by that mitigation.

4. Audit cloud and Kubernetes node patch status. Identify which nodes are running unpatched kernels and prioritize them for patching or live patching. For environments with KernelCare or equivalent live-patching services, patches are being prepared and will apply without a reboot.

5. Review access controls on shared Linux environments. Until patches are deployed, any user with shell access on an affected system can become root. Reduce the number of users with interactive access to sensitive nodes. SSH access to production infrastructure should be restricted, monitored, and require MFA.

6. Clear the page cache after applying the module blacklist. The echo 3 > /proc/sys/vm/drop_caches component of the mitigation command is important. If an exploit was already partially run before the blacklist was applied, the page cache may contain a contaminated version of /etc/passwd or /usr/bin/su. Dropping the page cache forces a reload from disk and clears any in-memory modifications.

Part II. Technical breakdown

Background: the page-cache write primitive class

Dirty Frag belongs to the same vulnerability family as Dirty Pipe (2022) and Copy Fail (CVE-2026-31431, April 2026). All three share the same underlying primitive: a page cache page that the attacker only has read permission on ends up inside a kernel data structure that is subsequently written to by a privileged kernel operation.

The page cache is the kernel's in-memory store for file contents. When a process reads a file, the kernel loads the file's pages into the page cache and returns them to the process. Subsequent reads return the cached copy rather than hitting the disk again. The key property for this vulnerability class is that the page cache is the authoritative copy of file data in RAM. A write to a page cache page changes what every subsequent reader of that file will see, even if the on-disk file is untouched.

splice() is a Linux system call that moves data between file descriptors through pipes without copying it through userspace. When used to move data from a regular file into a socket, splice() can plant a reference to the original page cache page directly into the kernel's socket buffer structure (struct sk_buff) without making a private copy. This is the zero-copy optimization that makes splice() efficient, and it is the precondition for the entire vulnerability class.

The vulnerability pattern, shared across all three bugs, is:

splice(file_fd -> pipe -> socket_fd)
  |
  v
Page cache page P (attacker has read-only access) is placed into
the skb's fragment slot WITHOUT being privately copied
  |
  v
Kernel's in-place crypto/protocol processing writes to the fragment
(treating it as a writable buffer it owns)
  |
  v
Page cache of the source file is now modified in RAM
  |
  v
Next read of any byte in that page returns the attacker-controlled value

In Copy Fail, the vulnerable sink was algif_aead in the AF_ALG crypto API. In Dirty Frag, it is the ESP input path (esp_input) and the RxRPC verification path (rxkad_verify_packet_1). The two differ in how attacker-controllable the written value is, which determines the exploitation strategy for each.

CVE-2026-43284: xfrm-ESP Page-Cache Write

Root cause

The vulnerability lives in esp_input() in net/ipv4/esp4.c (and the IPv6 equivalent in esp6.c). When an ESP packet arrives and the receiving socket buffer is non-linear (contains paged data rather than contiguous memory), the correct behavior is to call skb_cow_data() to allocate a private writeable copy of the paged data before performing in-place AEAD decryption. This copy-on-write operation ensures that the original page cache page is never written to.

The vulnerable path skips this copy. The decision logic is:

static int esp_input(struct xfrm_state *x, struct sk_buff *skb)
{
        [...]
        if (!skb_cloned(skb)) {
                if (!skb_is_nonlinear(skb)) {    // linear skb: skip cow, correct
                        nfrags = 1;
                        goto skip_cow;
                } else if (!skb_has_frag_list(skb)) {
                        nfrags = skb_shinfo(skb)->nr_frags;
                        nfrags++;
                        goto skip_cow;           // <-- BUG: nonlinear with frag, no frag_list
                }
        }
        err = skb_cow_data(skb, 0, &trailer);
        [...]

The second branch handles a non-linear skb that has fragment pages but no fragment list. When an attacker uses splice() to deliver a packet that includes a page cache page as frag[0], the skb exactly matches this condition: it is non-linear, it has a frag, and it has no frag_list. The code jumps to skip_cow and proceeds to decrypt in-place, operating directly on the page cache page.

The STORE itself comes from crypto_authenc_esn_decrypt(), which performs a sequence number rearrangement step before the actual decryption:

static int crypto_authenc_esn_decrypt(struct aead_request *req)
{
        [...]
        /* Move high-order bits of sequence number to the end. */
        scatterwalk_map_and_copy(tmp, src, 0, 8, 0);
        if (src == dst) {
                scatterwalk_map_and_copy(tmp, dst, 4, 4, 1);
                scatterwalk_map_and_copy(tmp + 1, dst,
                        assoclen + cryptlen, 4, 1);   // <-- STORE: 4 bytes at chosen offset

The four-byte STORE writes tmp + 1 (the high-order 32 bits of the ESP sequence number) to position assoclen + cryptlen in the destination SGL. Because src == dst and the destination SGL now contains the page cache page, this writes directly to the file's in-memory page. AEAD authentication fails afterward, but the STORE has already happened before the error is returned. The attacker gets the STORE regardless of whether the key or authentication tag are correct.

What the attacker controls

The value written is the high-order 32 bits of the XFRM SA's sequence number, specified via the XFRMA_REPLAY_ESN_VAL netlink attribute at SA registration time. The attacker has full control over this value and can write any four bytes.

The file offset of the write is controlled by tuning the ESP payload length: the position assoclen + cryptlen can be adjusted to land at any desired offset within the spliced page.

This gives a clean primitive: write four arbitrary bytes to any offset within the page cache of any file the attacker can open for reading.

Namespace requirement

Registering an XFRM SA requires CAP_NET_ADMIN. The exploit obtains this privilege by creating a new user+network namespace with unshare(CLONE_NEWUSER | CLONE_NEWNET). Unprivileged user namespace creation is enabled by default on most Linux distributions. Ubuntu's AppArmor policy sometimes restricts it, which is why the RxRPC variant exists as a fallback.

Exploit strategy for CVE-2026-43284

The target is /usr/bin/su. The exploit writes a 192-byte root shell ELF over the first 192 bytes of the file's page cache, split into 48 chunks of 4 bytes each. The crafted ELF maps a tiny R+X segment at 0x400000, and its entry point at 0x400078 executes:

setgid(0); setuid(0); setgroups(0, NULL);
execve("/bin/sh", NULL, ["TERM=xterm", NULL]);

After the 48 chunks are planted, the parent process calls execve("/usr/bin/su"). The setuid-root bit on su is intact, so the kernel elevates the process to euid=0 and executes the shellcode at the entry point. PAM is never invoked. The shell drops with root privileges.

The page cache modification persists until the kernel evicts the page or the system reboots. The exploit can force eviction by calling posix_fadvise(fd, POSIX_FADV_DONTNEED), returning the file to its unmodified on-disk state and covering tracks.

CVE-2026-43500: RxRPC Page-Cache Write

Root cause

The RxRPC protocol implementation uses rxkad_verify_packet_1() to verify data packets secured at the RXRPC_SECURITY_AUTH level. This function performs an in-place decryption of the first 8 bytes of the payload using pcbc(fcrypt):

static int rxkad_verify_packet_1(struct rxrpc_call *call,
                                  struct sk_buff *skb, ...)
{
        sg_init_table(sg, ARRAY_SIZE(sg));
        ret = skb_to_sgvec(skb, sg, sp->offset, 8);

        memset(&iv, 0, sizeof(iv));
        skcipher_request_set_crypt(req, sg, sg, 8, iv.x);  // src=dst: in-place
        ret = crypto_skcipher_decrypt(req);
        [...]

The skb_to_sgvec() call converts the skb's fragment directly into the SGL. A page cache page planted by splice() into the skb's frag becomes the SGL as-is. The crypto_skcipher_decrypt() call then performs an 8-byte in-place STORE on top of that page. The existing code only checked skb_cloned(skb) before this path; a non-linear skb carrying a splice-planted page is not cloned and therefore reaches the decrypt without triggering the copy-on-write path.

What the attacker controls

The value written is fcrypt_decrypt(C, K), where C is the 8 bytes at the target file offset (the ciphertext as seen by the kernel) and K is the 8-byte session key from an RxRPC v1 token the attacker registers via add_key("rxrpc", ...). Registering an RxRPC key requires no privileges.

Because fcrypt is a deterministic, portable block cipher with a 56-bit key, the attacker can brute-force K in userspace using a ported implementation at approximately 18 million keys per second. For targets with weak constraints on the desired plaintext (e.g. "any byte other than colon and newline"), the search completes in roughly one second.

Exploit strategy for CVE-2026-43500

The target is /etc/passwd, specifically line 1 (the root entry). The exploit transforms:

root:x:0:0:root:/root:/bin/bash

into:

root::0:0:GGGGGG:/root:/bin/bash

The passwd field (x) is replaced with an empty string. PAM's pam_unix.so with the nullok option (the Ubuntu default) accepts an empty password and returns PAM_SUCCESS without prompting. The exploit then calls execve("/usr/bin/su -"), which authenticates with an empty password and runs setresuid(0, 0, 0), dropping into a root shell.

The modification is performed in three overlapping 8-byte STOREs at file offsets 4, 6, and 8. Each STORE is preceded by a userspace brute-force search for the key K that produces the desired plaintext. Because each STORE affects bytes that the next STORE partially overlaps, the brute-force searches must account for the chained ciphertext state after each preceding STORE.

This variant requires no namespace creation privileges and works entirely through APIs available to any unprivileged user: add_key(), socket(AF_RXRPC), socket(AF_ALG) for checksum computation, splice(), and recvmsg().

How the two variants are chained

Neither variant alone works reliably across all major Linux distributions. The ESP variant has the more powerful primitive (arbitrary 4-byte write to any file offset, no brute force), but it requires namespace creation privileges that Ubuntu sometimes blocks. The RxRPC variant requires no privileges, but rxrpc.ko is not included in all distributions.

The two variants cover each other's blind spots:

[Exploit binary launches]
        |
        v
Attempt ESP variant:
  unshare(CLONE_NEWUSER | CLONE_NEWNET)
    |
    +-- Success: register XFRM SAs, splice /usr/bin/su, write 192-byte ELF
    |     |
    |     v
    |   Check: did shellcode land at /usr/bin/su entry offset?
    |     |
    |     +-- Yes: forkpty + execve("/usr/bin/su") -> root shell
    |
    +-- Failure (EPERM, esp4 not loaded, SA registration fails):
          Fall back to RxRPC variant:
            Brute-force K_A/K_B/K_C for /etc/passwd line 1
            Three splice + recvmsg triggers -> modify /etc/passwd page cache
            forkpty + execve("/usr/bin/su -") -> PAM nullok -> root shell

The result is a single binary that reliably roots all major Linux distributions, adapting to the capabilities available in the environment.

The patch

CVE-2026-43284 (ESP) patch (commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4, merged into netdev tree on May 7, 2026):

The fix introduces SKBFL_SHARED_FRAG flag tracking. When splice() appends pages to an IPv4/IPv6 datagram, the new code marks the skb with SKBFL_SHARED_FRAG. The skip_cow branch in esp_input and esp6_input now additionally checks this flag, routing shared-frag skbs to the skb_cow_data path:

- } else if (!skb_has_frag_list(skb)) {
+ } else if (!skb_has_frag_list(skb) &&
+            !skb_has_shared_frag(skb)) {

This ensures that attacker-pinned page cache pages never reach the writable destination SGL of the in-place AEAD.

CVE-2026-43500 (RxRPC) patch (submitted, not yet merged upstream as of May 8, 2026):

The fix adds a skb->data_len check alongside the existing skb_cloned() check before the in-place decrypt path. A non-linear skb with data_len > 0 indicates paged data (potential splice-planted pages) and must be copied before in-place processing:

- if (skb_cloned(skb)) {
+ if (skb_cloned(skb) || skb->data_len) {
        /* Unshare so that in-place decryption can proceed safely */

This routes splice-sourced skbs through skb_copy() rather than modifying the original fragments in place.

Detection

The module blacklist command is both the mitigation and the primary detection mechanism. Before applying it, defenders should check whether the three modules are currently loaded:

lsmod | grep -E 'esp4|esp6|rxrpc'

On systems where these modules should not be active (servers that do not run IPSec or AFS), their presence is worth investigating. The modules can be demand-loaded, so their absence from lsmod does not mean the exploit cannot load them. Check whether the blacklist file already exists:

ls -la /etc/modprobe.d/dirtyfrag.conf

For post-exploitation detection, the most reliable signal is unexpected modifications to /etc/passwd or /usr/bin/su in the page cache. These will not appear in file system audit logs (the on-disk files are not modified), but they will appear in process behavior: a process running as root that was launched by a non-root user via su without visible authentication is anomalous in any well-monitored environment.

The exploit also leaves a characteristic fingerprint in kernel audit logs if auditing is enabled: unshare(CLONE_NEWUSER | CLONE_NEWNET) followed by XFRM netlink socket activity from an unprivileged user is an unusual pattern outside of container runtimes. The RxRPC variant similarly produces an unusual pattern of add_key("rxrpc") calls followed by AF_RXRPC socket creation from a non-privileged process.

Timeline

What we should take away from Dirty Frag

The patterns embedded in this vulnerability class keep repeating, and they are worth naming precisely so they can inform how we think about kernel security going forward:

The same primitive survives in codebases that were not in scope for the original audit. Copy Fail was found in algif_aead. Dirty Frag was found in esp_input and rxkad_verify_packet_1. The root vulnerability is not module-specific: it is the general pattern of in-place crypto on kernel data structures that may contain attacker-controlled page cache pages via splice(). Finding and patching one instance does not mean the class is closed. It means the class has been found.

Chaining two weak primitives produces a more reliable exploit than either alone. CVE-2026-43284 alone cannot root Ubuntu when namespace creation is restricted. CVE-2026-43500 alone cannot root distributions that do not ship rxrpc.ko. Together, they cover all major distributions with a single binary. Vulnerability chaining is not an advanced technique here; it is a clean logical composition of two independently limited primitives. The class of "combine A and B to cover each other's gaps" will be reused.

A broken embargo is a forced full disclosure without patches. The Dirty Frag disclosure did not go wrong because of a vendor delay or a policy disagreement. It went wrong because a third party outside the coordinated disclosure process obtained the information during the embargo and published it. The consequence was that a working root exploit was publicly available while most distributions had not yet built their patched kernels. There is no obvious technical mitigation for this failure mode, but it is a realistic scenario that should factor into how organizations think about their preparedness between disclosure and patch availability.

"Local privilege escalation" is not a lower tier on shared infrastructure. The label local LPE implies the attacker must already be on the machine. On cloud VMs, CI/CD runners, shared hosting, and containerized workloads, being "on the machine" is the normal operational state for developers, service accounts, and application processes. The blast radius of a reliable kernel LPE in those environments is materially equivalent to a remote exploit on a single-tenant server.

How Pragma Core addresses this class of problem

Dirty Frag surfaces the same core challenge Copy Fail did, but with a harder dimension: the vulnerability class survived in the kernel for nine years precisely because auditing for it requires tracing a data flow across subsystem boundaries, not just reading a single function. The page-cache write primitive spans splice() in the VFS layer, packet framing in the networking stack, and in-place crypto in multiple protocol handlers. No conventional scanner traces that path.

Autonomous AI agents for cross-subsystem data flow analysis

The Pragma Core platform's autonomous research agents reason about how data moves across code boundaries. The page-cache write class is defined by a specific data flow: an attacker-controlled page reference enters a kernel buffer structure via splice(), survives into a code path that assumes it is privately owned, and is written to by a privileged operation. Identifying all instances of that flow in a codebase requires following data across function call chains and subsystem boundaries. That is precisely the kind of analysis our agents perform. For organizations that maintain kernel patches, driver code, or privileged system software, the same approach applied to your codebase identifies latent instances of this pattern before a researcher with a public PoC finds them.

Continuous SCA and kernel version tracking across your fleet

The immediate question after Dirty Frag is: which of our systems are running a vulnerable kernel, and which have received a patched one? In environments with hundreds or thousands of nodes, the answer is almost never "all of them" immediately after a patch becomes available. The Pragma Core SCA and dependency tracker maintains continuous kernel version coverage across connected environments and surfaces CVE matches the moment they are published. After patches begin rolling out, it tracks which nodes have applied them and which remain exposed, without requiring manual inventory queries across cloud accounts, Kubernetes clusters, and bare-metal fleets.

Runtime detection for anomalous kernel subsystem activity

The Dirty Frag exploit has a distinctive runtime signature: unshare(CLONE_NEWUSER | CLONE_NEWNET) followed by XFRM SA registration from an unprivileged user, or add_key("rxrpc") followed by AF_RXRPC socket creation from a process that has no legitimate reason to use the AFS protocol. These are not patterns that appear in normal application workloads. The Pragma Core platform connects runtime telemetry to CVE context, surfacing this kind of anomalous subsystem activity as a high-confidence signal worth treating as critical rather than noise. A Falco-style rule for the ESP variant would look like:

- rule: Unexpected Unprivileged XFRM SA Registration
  desc: >
    Detects XFRM netlink SA registration from an unprivileged user process
    preceded by user namespace creation. Mandatory first step of
    CVE-2026-43284 (Dirty Frag ESP variant).
  condition: >
    evt.type = unshare and evt.rawres >= 0
    and evt.arg.flags contains CLONE_NEWUSER
    and not proc.name in (known_container_runtimes)
  output: >
    Unprivileged XFRM namespace setup detected
    (proc.pid=%proc.pid proc.name=%proc.name
     proc.cmdline=%proc.cmdline container.name=%container.name)
  priority: CRITICAL
  tags: [host, container, kernel, CVE-2026-43284,
         MITRE_TA0004_privilege_escalation, MITRE_T1068]

Infrastructure penetration testing with kernel LPE coverage

The Pragma Core infrastructure penetration testing module covers local privilege escalation primitives on Linux hosts, including kernel LPE vectors in the post-disclosure window before all nodes are patched. For organizations that want to confirm whether Dirty Frag is exploitable in their specific kernel and configuration, an authenticated pentest against a representative node is more reliable than a version string check alone. Version checks do not account for backported patches, custom kernel builds, or module configuration differences across nodes.

Closing thoughts

Dirty Frag dropped into an already tense week for Linux kernel security. Copy Fail had just been added to CISA's Known Exploited Vulnerabilities catalog. Distributions were mid-stream on deploying Copy Fail patches. Into that context, a second public exploit arrived, using the same splice-based page-cache write class, requiring no patch for its RxRPC component, and bypassing the Copy Fail mitigation entirely.

The immediate response is clear: apply the module blacklist, then replace it with the patched kernel when your distribution makes it available. The harder response is asking what it means that this same class of vulnerability survived in two separate kernel subsystems for nine years, and that its disclosure was forced by an embargo break rather than coordinated with distributions having patched kernels ready.

The module blacklist is a one-line command. Apply it. If you want to talk about what continuous kernel security coverage looks like across your fleet, you can reach us at pragma-core.com.

Sources

• Hyunwoo Kim (@v4bel), Dirty Frag write-up, GitHub.com/V4bel/dirtyfrag, May 7, 2026.
• Tom's Hardware, Devastating 'Dirty Frag' exploit leaks out, gives immediate root access on most Linux machines since 2017, May 8, 2026.
• Help Net Security, Dirty Frag: Unpatched Linux vulnerability delivers root access (CVE-2026-43284, CVE-2026-43500), May 8, 2026.
• AlmaLinux, Dirty Frag (CVE-2026-43284, CVE-2026-43500) Patches Released, May 7-8, 2026.
• CloudLinux, Dirty Frag (CVE-2026-43284, CVE-2026-43500): Mitigation and Kernel Update, May 7-8, 2026.
• Ubuntu Security, Dirty Frag Linux kernel local privilege escalation vulnerability mitigations, May 8, 2026.
• Red Hat, RHSB-2026-003 Networking subsystem Privilege Escalation (CVE-2026-43284), May 8, 2026.
• Amazon Web Services, AWS Security Bulletin 2026-027-AWS, May 7, 2026.
• Tenable, Dirty Frag (CVE-2026-43284, CVE-2026-43500): FAQ, May 8, 2026.
• SANS ISC, Commentary by Yee Ching Tok on Dirty Frag chaining, May 8, 2026.
• Linux netdev tree, Commit f4c50a4034e6 (ESP shared-frag fix), May 7, 2026.
• Linux netdev mailing list, Kuan-Ting Chen shared-frag patch, May 4, 2026.