Dirty Frag CVE, Linux root through page-cache frags

Dirty Frag is a Linux local privilege escalation problem in the uncomfortable class of bugs where the kernel lets data that should be treated as externally backed or read-only become a write target through a fast path. The public Dirty Frag write-up describes it as a chain of two page-cache write vulnerabilities, xfrm-ESP Page-Cache Write and RxRPC Page-Cache Write, that can be used to obtain root on major Linux distributions. The researcher also places it in the same bug family as Dirty Pipe and Copy Fail, with an important operational point: the core exploit path is described as deterministic rather than race-dependent. (GitHub)

The name is not just branding. In Linux networking, packet data is represented through struct sk_buff metadata and associated buffers, including page fragments. Dirty Frag is about those fragments, ownership assumptions, and what happens when an in-place decrypt path modifies data that the socket buffer does not privately own. The NVD record for CVE-2026-43284 describes the ESP half of the issue clearly: MSG_SPLICE_PAGES can attach pages from a pipe directly to a socket buffer, TCP marks such buffers with SKBFL_SHARED_FRAG, but IPv4 and IPv6 datagram append paths did not set the same flag, leaving ESP input to treat externally backed fragments like ordinary nonlinear skb data and decrypt in place. (nvd.nist.gov)

The most important framing is simple. Dirty Frag is not a standalone remote code execution vulnerability. It is a local privilege escalation path. A remote attacker still needs a foothold first: a shell account, a compromised web process, a malicious CI job, a container escape setup, a build worker execution primitive, or another way to run low-privileged code on the target machine. Once that low-privileged execution exists, the impact can become root on the node. Red Hat’s advisory states that a user with a local account could trigger the Dirty Frag flaws to gain root privileges, and Red Hat classified the impact as Important while it worked on fixes. (레드햇 고객 포털)

The current CVE picture needs precision. CVE-2026-43284 is published by NVD for the xfrm ESP issue, with the description centered on avoiding in-place decrypt on shared skb fragments. At the same time, several vendor and researcher pages track the RxRPC half as CVE-2026-43500, but public database synchronization was still catching up when early advisories were written. AlmaLinux states that CVE-2026-43284 covers the IPsec ESP half and that CVE-2026-43500 tracks the RxRPC half with NVD publication pending, while the Dirty Frag repository’s 2026-05-08 update says the xfrm-ESP issue has CVE-2026-43284 and the RxRPC issue has been reserved as CVE-2026-43500 for tracking. (AlmaLinux OS)

The facts that matter first

Dirty Frag matters most on systems where low-privileged code execution is normal or easy to obtain. Shared hosting nodes, student lab machines, CI runners, container build farms, Kubernetes workers, OpenShift clusters, multi-user research servers, jump boxes, and cloud VMs that run untrusted workloads all deserve fast attention. A single-user laptop with no untrusted local execution is still affected if the kernel is vulnerable, but the practical risk is lower than on a multi-tenant node.

Dirty Frag is also not just “another kernel bug” in the abstract. It is one of several recent Linux vulnerabilities that expose a recurring failure mode: a high-performance zero-copy or in-place operation crosses a trust boundary that was not explicitly marked, copied, or isolated. Dirty Pipe abused pipe buffer state. Copy Fail abused AF_ALG, AEAD in-place operation, splice(), and page-cache-backed data. Dirty Frag moves the same class of invariant failure into networking fragments and decrypt paths. NVD describes Dirty Pipe, CVE-2022-0847, as a flaw where uninitialized pipe buffer flags let a local unprivileged user write to page-cache-backed pages for read-only files and escalate privileges. (nvd.nist.gov)

The fix path is also practical but disruptive. If a patched vendor kernel is available for your distribution and release stream, install it and reboot into it. If a livepatch from your vendor exists and matches your kernel, verify that it is active. If neither is available, temporary mitigations commonly involve preventing the affected modules from loading and unloading them if already present. AWS advises checking whether esp4, esp6, ipcomp4, ipcomp6또는 rxrpc are loaded, disabling future loading if appropriate, and considering user.max_user_namespaces=0 for the namespace-related vector. (Amazon Web Services, Inc.)

Do not apply module blacklists blindly. esp4 그리고 esp6 are used for kernel-side IPsec ESP processing, and disabling them can break IPsec tunnels on hosts that terminate or transit strongSwan, Libreswan, or similar deployments. CloudLinux explicitly warns that disabling esp4 그리고 esp6 breaks IPsec tunnels that rely on the kernel data path, while rxrpc is mostly relevant to AFS clients and is not typically present on ordinary web-hosting servers. (blog.cloudlinux.com)

What Dirty Frag is

Dirty Frag is best understood as an ownership bug. The kernel receives or builds a packet representation. That representation includes fragments that point to pages. Some pages are privately owned by the skb path and can be modified safely. Other pages are externally backed, shared, pinned, or derived from a zero-copy transfer path. The exploit class appears when a later kernel path fails to distinguish those cases and writes into a page that should not be modified through that path.

The Linux kernel documentation for struct sk_buff says an skb is the main networking structure representing a packet, but the structure itself is metadata and does not hold all packet data. The packet data lives in associated buffers, including an array of page fragments in skb_shared_info. That design is central to networking performance because the kernel can avoid repeatedly copying packet payloads, but it also means every path that might modify packet data must know whether it owns the backing memory. (docs.kernel.org)

The other important primitive is splice(). Kernel documentation describes 스플라이스 as a method for moving blocks of data inside the kernel without continually transferring them between kernel and user space. The man page similarly says splice() moves data between two file descriptors without copying between kernel address space and user address space, with one file descriptor referring to a pipe. That is not dangerous by itself. It is a performance feature. It becomes dangerous when a later subsystem forgets that the data it received may still be backed by pages the caller can reference. (docs.kernel.org)

The Dirty Frag ESP path involves IPsec. Linux’s XFRM framework is the kernel infrastructure for IP transformations such as IPsec, and kernel documentation describes ESP offload flows where encryption and decryption may happen in hardware or software while the kernel coordinates Security Associations and policies. Dirty Frag does not require a production IPsec tunnel to be valuable to an attacker. The issue is that ESP processing code exists in the kernel and can be reached under certain local conditions. (kernel.org)

The RxRPC path involves a less common protocol family. Kernel documentation describes RxRPC as a reliable two-phase transport over UDP, exposed through sockets of the AF_RXRPC family using sendmsg() 그리고 recvmsg(). AFS is one example of an application family that uses RxRPC. In normal enterprise web stacks, RxRPC is often irrelevant. In Dirty Frag, however, the RxRPC half matters because it can cover cases where the xfrm ESP half is blocked by namespace policy or module availability. (docs.kernel.org)

CVE-2026-43284 and the ESP half

CVE-2026-43284 is the cleaner public anchor for Dirty Frag because NVD has a record for it. The NVD description says the resolved Linux kernel issue is xfrm: esp: avoid in-place decrypt on shared skb frags. The problem starts with pages from a pipe being attached directly to an skb through MSG_SPLICE_PAGES. TCP marks those buffers with SKBFL_SHARED_FRAG, but IPv4 and IPv6 datagram append paths did not set the flag when splicing pages into UDP skbs. That omission made an ESP-in-UDP packet built from shared pipe pages look like an ordinary uncloned nonlinear skb. (nvd.nist.gov)

The dangerous next step is the fast path. ESP input can take a no-copy-on-write path for an uncloned skb without a frag_list. If the skb contains externally backed fragments but is not marked as such, ESP input may decrypt in place over data not privately owned by the skb. The fix described by NVD is twofold: mark IPv4 and IPv6 datagram splice fragments with SKBFL_SHARED_FRAG, matching TCP, and make ESP input fall back to skb_cow_data() when that flag is present. (nvd.nist.gov)

That patch is conceptually small but security-significant. It does not ban zero-copy networking. It does not remove ESP. It restores the invariant that mutable decrypt operations must not write into externally backed fragments. The Dirty Frag write-up’s patch section says the fix sets SKBFL_SHARED_FRAG on page fragments that came in through 스플라이스 in IPv4 and IPv6 datagram append paths, then checks that flag in the ESP input skip-COW branch so attacker-pinned page-cache pages cannot enter the destination scatter-gather list of the in-place AEAD operation. (GitHub)

That is also why a version-only check can mislead. The vulnerable upstream lifetime matters, but distribution kernels are heavily backported. A RHEL, Debian, Ubuntu, SUSE, Amazon Linux, or AlmaLinux kernel can carry a fix without matching a vanilla upstream version string that looks “new enough.” Conversely, an older LTS kernel can be vulnerable if it backported the affected feature set but not the security fix. Treat vendor advisories and package changelogs as stronger evidence than a generic upstream version comparison.

CVE-2026-43500 and the RxRPC half

The RxRPC half is harder to write about because public status moved quickly. The Dirty Frag repository states that the RxRPC Page-Cache Write vulnerability has been reserved as CVE-2026-43500 for tracking and, at the time of the update, no patch existed in any tree. AlmaLinux says the same half is tracked as CVE-2026-43500 with the NVD entry pending publication. That is enough to discuss it as part of Dirty Frag, but not enough to invent final scoring, final affected version tables, or final patch status beyond what vendors have published. (GitHub)

The reason RxRPC matters is coverage. The researcher explains that xfrm-ESP Page-Cache Write gives a powerful arbitrary four-byte store primitive and is present on most distributions, but it can require the privilege to create a namespace. Ubuntu sometimes blocks unprivileged user namespace creation through AppArmor policy, which can make the ESP half harder to trigger. The RxRPC half does not require namespace creation, but the rxrpc.ko module is not included or loaded the same way across distributions. The chain combines the two to reduce blind spots across major Linux distributions. (GitHub)

For defenders, that means the mitigation question is not “do we use RxRPC as an application protocol?” The better question is whether the module is present, loadable, or already loaded, and whether untrusted local code can trigger the relevant path. On ordinary servers, rxrpc may not be loaded at all. On systems with AFS, research environments, older infrastructure, or custom kernel usage, assuming absence is a mistake. Kernel documentation ties RxRPC to AF_RXRPC sockets and AFS use cases, which gives defenders a starting point for environment-specific baselining. (docs.kernel.org)

Dirty Pipe, Copy Fail, and Dirty Frag compared

Dirty Frag is easier to prioritize if it is compared to the older “Dirty” bugs by mechanism rather than nickname.

취약성	Public identifier	Core primitive	Main subsystem	Exploit condition	Defensive lesson
Dirty COW	CVE-2016-5195	Write through broken copy-on-write handling	Memory management	Local code execution, race-dependent	Read-only mappings need correct COW boundaries
더티 파이프	CVE-2022-0847	Write to page-cache-backed read-only files	Pipe buffers and page cache	Local unprivileged code execution	Pipe/page flags must be initialized and respected
Copy Fail	CVE-2026-31431	Controlled four-byte page-cache write	AF_ALG, algif_aead, authencesn, splice	Local unprivileged code execution	In-place crypto and zero-copy I/O need strict source and destination separation
Dirty Frag	CVE-2026-43284 and CVE-2026-43500 tracking	Page-cache write through skb fragments	xfrm ESP, RxRPC, skb frags	Local unprivileged code execution with distro-specific paths	Networking fragments must preserve ownership and shared-frag metadata

Dirty COW belongs in the comparison because it is the famous older Linux local privilege escalation bug that turned a copy-on-write invariant failure into unauthorized writes. NVD describes CVE-2016-5195 as a race condition in Linux kernel memory handling that allowed local users to gain privileges by leveraging incorrect handling of copy-on-write to write to read-only memory mappings. (nvd.nist.gov)

Dirty Pipe sharpened the page-cache angle. NVD describes CVE-2022-0847 as an issue where pipe buffer flags lacked proper initialization, allowing an unprivileged local user to write to pages in the page cache backed by read-only files and escalate privileges. Dirty Pipe was assigned a CVSS 3.1 score of 7.8 by NVD and is listed by NVD as present in CISA’s Known Exploited Vulnerabilities Catalog. (nvd.nist.gov)

Copy Fail is the closest predecessor. NVD’s CVE-2026-31431 record says the Linux kernel fix reverted algif_aead back to out-of-place operation because source and destination came from different mappings and the in-place complexity had no benefit. Microsoft describes Copy Fail as a high-severity local privilege escalation affecting major Linux distributions, requiring local low-privileged execution and enabling root escalation through corruption of readable file cache, including setuid binaries. (nvd.nist.gov)

Sysdig’s Copy Fail analysis is useful because it explains the mechanics in a way that also illuminates Dirty Frag. Copy Fail chained AF_ALG socket creation, splice() of page-cache pages from /usr/bin/su, and an AEAD receive path that placed controlled bytes into the page cache. The HMAC check could fail, but the page-cache corruption persisted. Dirty Frag is not the same bug, but the uncomfortable invariant is similar: a path designed for performance treats referenced file-backed pages as writable implementation detail. (sysdig.com)

The main difference is the subsystem. Copy Fail is centered on the kernel crypto userspace API, AF_ALG, and algif_aead. Dirty Frag’s ESP half is centered on networking skbs, UDP datagram append behavior, MSG_SPLICE_PAGES, and ESP input. Dirty Frag’s RxRPC half is centered on AF_RXRPC and its receive handling. From an incident response standpoint, that difference changes telemetry. AF_ALG-only detection is useful for Copy Fail but does not prove full Dirty Frag coverage.

Why page-cache writes are so dangerous

A page-cache write primitive is not just a memory corruption bug with a strange name. The page cache is the kernel’s in-memory cache of file contents. If an attacker can modify the cached bytes of a privileged executable without changing the file on disk, the running system can observe attacker-controlled bytes while disk-based integrity checks still see the original file. That is why this class of bugs is so attractive for local privilege escalation.

A common exploit pattern is to target a setuid-root binary. The attacker does not need to permanently overwrite the disk file. The attacker needs the kernel to execute the modified cached version long enough to transition into privileged code. Public Dirty Frag material describes assembling a small ELF payload on top of page cache and then executing /usr/bin/su so the modified copy is mapped into the new process; after the setuid-root transition, the payload runs with root privileges. (GitHub)

That description is enough for defenders. There is no need to run public exploit code on production hosts to “confirm” risk. In fact, the Dirty Frag repository warns that after running the exploit, the page cache is contaminated and should be cleared with drop_caches or by rebooting. CloudLinux similarly warns that applying mitigation alone is not enough if a system may already have been targeted, because the exploit can modify legitimate system binaries in page cache as part of gaining root. (GitHub)

This is also why ordinary file integrity tooling can be incomplete. Hashing /usr/bin/su from disk may show the expected bytes while a cached page has already been modified in memory. Rebooting clears page cache, but rebooting without installing a fixed kernel simply returns the machine to a vulnerable state. Dropping caches can remove polluted cached pages, but it is not a patch. The long-term fix is a corrected kernel path that prevents externally backed pages from entering the mutable destination side of the operation.

Who is exposed

The hardest part of Dirty Frag response is not understanding that kernel root is bad. It is deciding where to spend the first hour.

The highest-risk systems are those where untrusted local code execution is part of normal operations. A CI runner that executes pull requests, package build scripts, test harnesses, or student exercises is high risk. A Kubernetes worker that runs untrusted containers is high risk. A shared hosting server with many shell users is high risk. A multi-user research host is high risk. A cyber range is high risk. A web server with a recently exploited application bug is high risk because local privilege escalation becomes the second stage after initial compromise.

Red Hat confirmed that Red Hat Enterprise Linux 10, 9, and 8 and OpenShift 4 were affected while investigation was ongoing. Red Hat’s mitigation language also calls out measures that reduce local-access risk, including limiting SSH, keeping SELinux enforcing, using default Security Context Constraints, running workloads as non-root, and restricting oc debug access to trusted cluster administrators. Those controls do not fix the kernel flaw, but they reduce the number of paths by which an attacker can reach local code execution. (레드햇 고객 포털)

Debian’s tracker gives a good example of why release-specific status matters. At the time queried, Debian listed multiple linux source package releases such as bullseye, bookworm, trixie, and forky as vulnerable, while sid showed a fixed version. That is not a universal statement about all Linux; it is a reminder that distribution security trackers should be checked directly for the exact release and package stream you run. (Security Tracker)

AlmaLinux moved quickly with patched kernels in testing. Its advisory states that AlmaLinux 8 is patched in kernel-4.18.0-553.123.2.el8_10 and above, AlmaLinux 9 in kernel-5.14.0-611.54.3.el9_7 and above, and AlmaLinux 10 in kernel-6.12.0-124.55.2.el10_1 and above. That information is useful for AlmaLinux users but should not be copy-pasted to RHEL, Rocky, Oracle Linux, Debian, Ubuntu, SUSE, or Amazon Linux without checking their own vendor channels. (AlmaLinux OS)

AWS’s advisory uses a broader module list than some early community mitigations. It says issues commonly referred to as DirtyFrag are present in loadable modules including xfrm_user, esp4, esp6, ipcomp4및 ipcomp6, and it also tells customers to check rxrpc. It ties exploitation risk to systems that allow unprivileged users to create sockets directly or through CAP_NET_ADMIN, or allow creation of unprivileged user and network namespaces. (Amazon Web Services, Inc.)

Safe exposure checks

The following checks are safe inventory steps. They do not exploit the vulnerability. They help answer three questions: what kernel is running, which relevant modules are present or loaded, and whether local untrusted code has namespace or capability paths that increase exploitability.

#!/usr/bin/env bash
set -euo pipefail

echo "[kernel]"
uname -a
printf "release: "
uname -r

echo
echo "[loaded modules of interest]"
lsmod | awk 'NR==1 || /^(esp4|esp6|rxrpc|ipcomp4|ipcomp6|xfrm_user)\b/'

echo
echo "[module availability checks]"
for m in esp4 esp6 rxrpc ipcomp4 ipcomp6 xfrm_user; do
  if modinfo "$m" >/dev/null 2>&1; then
    echo "$m: present"
  else
    echo "$m: not found by modinfo"
  fi
done

echo
echo "[namespace settings]"
sysctl user.max_user_namespaces 2>/dev/null || true
sysctl kernel.unprivileged_userns_clone 2>/dev/null || true

echo
echo "[existing Dirty Frag mitigation files]"
grep -R --line-number -E 'install (esp4|esp6|rxrpc|ipcomp4|ipcomp6|xfrm_user) /bin/false' \
  /etc/modprobe.d 2>/dev/null || true

The output is not a vulnerability verdict by itself. A module can be present but not loaded. A module can be loadable only by privileged users in one environment and autoloadable in another. A namespace setting can be disabled but another path may still exist through a process with CAP_NET_ADMIN. Treat the script as a triage helper, not as a scanner with a clean pass or fail.

For Debian and Ubuntu family systems, package-level checks should include the installed kernel package, the running kernel, and any pending security updates.

echo "[running kernel]"
uname -r

echo "[installed linux image packages]"
dpkg -l 'linux-image*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

echo "[available upgrades related to kernel]"
apt list --upgradable 2>/dev/null | grep -E 'linux-image|linux-modules|linux-generic' || true

For RHEL, Fedora, AlmaLinux, Rocky, Oracle Linux, Amazon Linux, and CloudLinux family systems, use package manager metadata and vendor advisories rather than upstream version guessing.

echo "[running kernel]"
uname -r

echo "[installed kernels]"
rpm -q kernel kernel-core 2>/dev/null || true

echo "[available kernel updates]"
dnf check-update 'kernel*' 2>/dev/null || true

For Kubernetes or OpenShift nodes, the key is to map workload risk to node kernel risk. A pod running as non-root is still local code execution on the host kernel. Non-root containers reduce many risks, but they do not remove the kernel attack surface. Red Hat specifically calls out OpenShift 4 as affected and recommends hardening measures such as default SCCs, non-root workloads, and restricting debug access while fixes are being prepared. (레드햇 고객 포털)

Temporary mitigations and their trade-offs

Kernel updates are the real fix. Temporary mitigations are for the gap between disclosure and a verified patched kernel. The common mitigation is to prevent affected modules from loading and unload them if already loaded. CloudLinux suggests blacklisting esp4, esp6및 rxrpc until a patched kernel or livepatch is installed. AWS additionally names ipcomp4 그리고 ipcomp6 in its affected module set. (blog.cloudlinux.com)

A cautious mitigation file can be created like this on systems where you have verified that these modules are not required for production traffic:

sudo install -m 0644 /dev/null /etc/modprobe.d/dirtyfrag.conf

cat <<'EOF' | sudo tee /etc/modprobe.d/dirtyfrag.conf >/dev/null
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
install ipcomp4 /bin/false
install ipcomp6 /bin/false
EOF

sudo rmmod esp4 esp6 rxrpc ipcomp4 ipcomp6 2>/dev/null || true

After a patched kernel is installed and booted, remove the temporary mitigation only if the modules are actually needed:

sudo rm -f /etc/modprobe.d/dirtyfrag.conf
sudo depmod -a

If you suspect exploitation before mitigation, do not rely on the blacklist alone. Clear page cache or reboot after preserving forensic evidence where needed. CloudLinux explicitly warns that the exploit can modify legitimate system binaries in page cache and recommends dropping page cache after mitigation on systems that may have been targeted. (blog.cloudlinux.com)

# Use only after assessing operational impact.
# This can disrupt performance because it drops clean page cache.
sync
echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

A stronger but blunt runtime option is to disable all future module loading until reboot:

sudo sysctl -w kernel.modules_disabled=1

AWS mentions this as an alternative if affected modules are not currently loaded, but the trade-off is significant: once set, it is permanent until the next reboot. Do not use it on systems that may need to load storage, network, security, or hardware modules later in the same boot session. (Amazon Web Services, Inc.)

For namespace hardening, this setting may reduce a known Dirty Frag path on some hosts:

sudo sysctl -w user.max_user_namespaces=0

That can break rootless containers, unprivileged user namespace workflows, sandboxing tools, and developer environments. It is a serious operational change, not a cosmetic hardening tweak. AWS lists it as a mitigation for the namespace-specific vector; Red Hat separately warns that disabling any single access method does not eliminate every other way a user might gain local access. (Amazon Web Services, Inc.)

Patch verification

A patched package is not the same as a patched running kernel. Linux systems frequently install a new kernel package but continue running the old kernel until reboot. Livepatching changes that equation, but only if the livepatch is actually loaded and covers the relevant CVE or patch.

For regular kernel updates, verify all three states:

echo "[running kernel]"
uname -r

echo "[booted kernel image]"
cat /proc/version

echo "[installed kernel packages]"
if command -v rpm >/dev/null 2>&1; then
  rpm -q kernel kernel-core 2>/dev/null || true
fi

if command -v dpkg >/dev/null 2>&1; then
  dpkg -l 'linux-image*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
fi

For AlmaLinux, compare against the fixed versions in the AlmaLinux advisory if you are using AlmaLinux repositories. For CloudLinux, CloudLinux says CL9 and CL10 use the AlmaLinux kernel directly, while CL7h and CL8 use CloudLinux kernel streams, so the correct verification path depends on the stream. CloudLinux also states that KernelCare livepatches were being prepared and that kcarectl --patch-info | grep [CVE-2026-43284] can be used when the relevant livepatch is available. (blog.cloudlinux.com)

# KernelCare verification pattern, when applicable to your vendor stream.
sudo kcarectl --update
sudo kcarectl --patch-info | grep -E 'CVE-2026-43284|Dirty Frag' || true

For Debian, use Debian’s tracker rather than a generic kernel version statement. Its CVE-2026-43284 page listed specific release/package statuses, including vulnerable entries for several stable releases and fixed status for sid at the time queried. That can change quickly, which is exactly why package metadata and official trackers should be part of every remediation runbook. (Security Tracker)

Detection engineering

Dirty Frag detection is harder than Copy Fail detection because there is no single obvious AF_ALG event that covers the whole issue. Copy Fail detection often starts with AF_ALG socket creation, because AF_ALG is the userspace crypto API family and Copy Fail’s public chain depends on it. Dirty Frag’s ESP half is a networking path, not the same AF_ALG chain. Dirty Frag’s RxRPC half may involve AF_RXRPC, which is rare in most environments but legitimate in AFS-related systems.

The strongest detection strategy is layered. Start with exposure, then add behavior.

Exposure signals:

신호	중요한 이유	Useful on
esp4, esp6, rxrpc, ipcomp4, ipcomp6 loaded	Confirms relevant modules are active	Servers, CI, Kubernetes nodes
Unprivileged user namespaces enabled	Can enable paths requiring user and net namespace creation	Container hosts, developer boxes
CAP_NET_ADMIN granted to untrusted workloads	Allows network namespace and XFRM manipulation paths	Kubernetes, containers, CI
AF_RXRPC socket creation by non-baseline process	RxRPC is uncommon outside AFS-related use	General servers
NETLINK_XFRM activity by unexpected process	XFRM config is normally done by IPsec tooling or privileged network agents	VPN, container, network hosts
Execution of su, sudo, or setuid binaries after suspicious local build or network setup	Potential privilege transition after page-cache manipulation	All Linux hosts

A lightweight auditd baseline can watch for module and namespace activity. The exact syscall filters vary by architecture and auditd version, so treat this as a starting point.

# Module loading and unloading.
sudo auditctl -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kernel-module-change

# Namespace creation through unshare and clone3.
sudo auditctl -a always,exit -F arch=b64 -S unshare,clone,clone3 -k namespace-create

# Suspicious direct execution of common setuid transition tools.
sudo auditctl -w /usr/bin/su -p x -k su-exec
sudo auditctl -w /usr/bin/sudo -p x -k sudo-exec
sudo auditctl -w /usr/bin/passwd -p x -k passwd-exec

Falco-style runtime rules can add higher-level context. This example focuses on rare AF_RXRPC socket creation and unexpected module changes. It is not a complete Dirty Frag detector.

- list: expected_rxrpc_processes
  items: [afs, afsd, kafs, systemd, modprobe]

- rule: Unexpected AF_RXRPC socket creation
  desc: Detect AF_RXRPC socket creation by a process outside the local baseline
  condition: >
    evt.type=socket and evt.rawres >= 0 and
    evt.rawarg.domain=33 and
    not proc.name in (expected_rxrpc_processes)
  output: >
    Unexpected AF_RXRPC socket created
    user=%user.name proc=%proc.name cmd=%proc.cmdline container=%container.id
  priority: WARNING
  tags: [linux, dirtyfrag, rxrpc, privilege_escalation]

- rule: Sensitive kernel module change
  desc: Detect load or unload attempts for modules associated with Dirty Frag exposure
  condition: >
    spawned_process and
    proc.name in (modprobe, insmod, rmmod) and
    proc.cmdline contains "esp4" or
    proc.cmdline contains "esp6" or
    proc.cmdline contains "rxrpc" or
    proc.cmdline contains "ipcomp4" or
    proc.cmdline contains "ipcomp6"
  output: >
    Kernel module change involving Dirty Frag related module
    user=%user.name proc=%proc.name cmd=%proc.cmdline container=%container.id
  priority: WARNING
  tags: [linux, dirtyfrag, kernel_module]

The AF_RXRPC address family value is environment-dependent only in the sense that your telemetry product may display symbolic names or raw numbers differently. Linux kernel documentation describes AF_RXRPC sockets as the interface for RxRPC. If your sensor exposes symbolic values, prefer AF_RXRPC over a raw integer. If it exposes raw syscall arguments, confirm the constant against the exact headers used by your distribution and sensor. (docs.kernel.org)

For XFRM, do not alert on every XFRM event in an IPsec environment. VPN gateways, service meshes, node agents, and network daemons can legitimately configure XFRM state. A better query is “unexpected process plus unexpected user plus unexpected namespace plus XFRM activity.” The Linux netlink header defines NETLINK_XFRM as the IPsec netlink family, but raw netlink activity alone is noisy without process context. (Android GoSource)

A simple process-baseline hunt can be useful on hosts where untrusted users should never compile or execute native code:

# Recent compiler usage by non-root users.
ausearch -k execve 2>/dev/null | grep -E 'gcc|clang|cc|make' || true

# Recent executions of setuid-root transition tools.
ausearch -k su-exec -k sudo-exec -k passwd-exec 2>/dev/null || true

# Kernel module changes.
ausearch -k kernel-module-change 2>/dev/null || true

# Namespace creation events.
ausearch -k namespace-create 2>/dev/null || true

This is not meant to replace EDR, eBPF-based runtime security, or kernel-level telemetry. It gives incident responders a quick way to ask whether suspicious local preparation occurred around the same time as privilege transitions.

Containers, CI runners, and shared hosts

Dirty Frag should change how teams think about “low privilege” in containerized and build environments. A container shell is not root on the host, but it is code running on the host kernel. A CI job is not a sysadmin account, but it is code running on a shared worker kernel. A shared hosting account is not root, but it is local execution on a multi-tenant machine. Local privilege escalation bugs convert those assumptions into root-risk questions.

Microsoft made the same point for Copy Fail, noting that successful exploitation could facilitate container breakout, multi-tenant compromise, and lateral movement in shared environments. That statement was about CVE-2026-31431, not Dirty Frag, but the operational reasoning applies to Dirty Frag because the first stage is local code execution and the target is the shared kernel. (Microsoft)

Kubernetes hardening can reduce blast radius but should not be mistaken for a kernel patch. Good controls include denying unnecessary capabilities, avoiding privileged pods, using seccomp profiles that actually block unneeded socket families, preventing hostPath mounts where possible, keeping nodes single-tenant for untrusted workloads, and draining vulnerable nodes during emergency patching. Red Hat’s OpenShift guidance points in the same direction: default SCCs, non-root workloads, SELinux enforcing mode, and restricted debug access reduce risk while fixes are prepared. (레드햇 고객 포털)

CI runners deserve special urgency. They often execute code from branches, forks, packages, or test fixtures that security teams would never run on a production server. They also tend to carry signing keys, deployment tokens, artifact credentials, cloud metadata access, or internal network reachability. A kernel LPE on a runner can become a supply-chain event.

For GitHub Actions self-hosted runners, GitLab runners, Jenkins workers, Buildkite agents, Drone runners, or custom build farms, the minimum response should be to patch or rebuild the worker image, rotate any secrets that may have been exposed on vulnerable multi-tenant workers, clear compromised workers rather than trusting them, and separate untrusted pull-request execution from privileged release jobs. Dirty Frag is a kernel issue, so rebuilding only the application container is not enough if the worker node remains vulnerable.

Practical remediation runbook

Start with scope.

Identify all Linux systems that allow untrusted or semi-trusted local code execution. Put CI runners, Kubernetes workers, shared hosting, student labs, bastions with shell users, and multi-user compute nodes in the first wave. Then identify public-facing Linux servers where application compromise could provide a local foothold. Put single-user workstations and tightly isolated appliances later unless they carry privileged workloads or sensitive credentials.

Next, collect kernel and module status. Store results centrally so you can prove what was checked and when.

hostname -f
date -u
uname -r
lsmod | grep -E '^(esp4|esp6|rxrpc|ipcomp4|ipcomp6|xfrm_user)\b' || true
sysctl user.max_user_namespaces 2>/dev/null || true
sysctl kernel.unprivileged_userns_clone 2>/dev/null || true

Then check vendor status. Use distribution advisories, not generic blog tables. AlmaLinux, CloudLinux, Red Hat, AWS, and Debian had public Dirty Frag pages or trackers quickly, but their statuses and package names differ. Red Hat’s bulletin confirmed affected products while stating that specific mitigation guidance would be provided; AlmaLinux published testing kernels with explicit fixed package versions; AWS provided module and namespace mitigations while updates were being prepared; Debian’s tracker showed release-by-release package status. (레드햇 고객 포털)

Apply patches where available. Reboot unless using a verified livepatch. Confirm the running kernel changed. On container hosts, drain workloads first. On multi-tenant servers, coordinate a maintenance window, but do not let convenience push this below ordinary application patching.

If patches are not available, apply temporary module mitigations only after checking IPsec and RxRPC dependencies. On IPsec gateways, do not disable ESP modules without a failover plan. On AFS clients, do not disable RxRPC without understanding service impact. Where untrusted local users are present, consider disabling unprivileged user namespaces if operationally possible. Where container runtime profiles can deny relevant socket families without breaking workloads, deploy narrower seccomp controls.

After mitigation, clear page cache or reboot if there is any chance of prior exploitation. Preserve memory, logs, and forensic artifacts first if you suspect active compromise. Page-cache contamination can disappear on reboot, but so can volatile evidence.

Finally, add detection and regression checks. A one-time patch sprint is not enough if your cloud images, golden AMIs, base VM templates, and CI worker pools keep reintroducing vulnerable kernels. Add a policy that rejects vulnerable node images and checks module status before workers join untrusted pools.

Penligent’s workflow is relevant in the validation phase rather than as a replacement for kernel patching. For authorized environments, teams can use an agentic AI pentesting process to keep CVE triage, target inventory, evidence capture, command history, and retest reports in one place, while avoiding unsafe production execution of public kernel LPE PoCs. Penligent’s own site describes CVE scanning, vulnerability validation, and evidence-first reporting, and its existing Copy Fail analysis is a directly related reference for the same page-cache write family. (penligent.ai)

Common mistakes

The first mistake is treating Dirty Frag as remote code execution. It is not. The attacker needs local code execution or an equivalent foothold. That distinction matters for exposure ranking, but it should not lower urgency on systems that intentionally run untrusted code.

The second mistake is treating a container boundary as a kernel boundary. Containers share the host kernel. If a local kernel LPE is reachable from a container, “non-root in the container” does not automatically protect the node.

The third mistake is checking only /usr/bin/su 또는 /usr/bin/sudo hashes. Page-cache modification may not alter the disk file. Disk integrity checks can be clean while memory is polluted. Use kernel patching, reboot or cache clearing, runtime telemetry, and forensic judgment together.

The fourth mistake is blacklisting modules without business context. Disabling esp4 그리고 esp6 can break IPsec. Disabling rxrpc can affect AFS. Disabling all future module loading with kernel.modules_disabled=1 can break operations before reboot. Temporary mitigations are controls with blast radius, not free security.

The fifth mistake is assuming that a CVE score tells the whole story. NVD had not yet provided a CVSS assessment for CVE-2026-43284 at the time of the NVD record shown, while Red Hat classified the Dirty Frag issue as Important. Meanwhile, practical urgency depends heavily on whether the host is multi-tenant or executes untrusted jobs. (nvd.nist.gov)

The sixth mistake is using public exploit success as a validation method. Public PoCs for local kernel LPEs can leave the system in a contaminated or unstable state. Use vendor patch checks, safe module and namespace inventory, controlled lab reproduction if necessary, and runtime detection. Do not run untrusted exploit code on production systems.

A defensible priority model

A useful priority model starts with the attacker’s first foothold.

우선순위	System type	Reason	액션
1	CI runners and build workers	Untrusted code execution is common and secrets are nearby	Patch or rebuild immediately, rotate exposed secrets if compromise is suspected
1	Kubernetes and OpenShift worker nodes	Containers share the kernel, and node compromise can affect many workloads	Drain, patch, reboot, verify node kernel before rescheduling
1	Shared hosting and multi-user shell servers	Any local user can become the starting point	Patch fast, consider temporary module mitigation, audit setuid executions
1	Student labs and cyber ranges	Users intentionally run arbitrary code	Patch or isolate, reset nodes between users
2	Public-facing app servers	Web RCE can become local LPE	Patch after highest-risk multi-tenant nodes, review app compromise signals
2	VPN and IPsec infrastructure	ESP modules may be required, so mitigation is delicate	Prefer patched kernel or controlled failover over module blacklisting
3	Single-user desktops	Requires local malicious execution	Patch through normal emergency channel
3	Isolated appliances	Exposure depends on vendor kernel and local access	Track vendor firmware or appliance advisory

This model is intentionally operational. A vulnerability can be technically severe on every Linux host but operationally urgent on the systems where local execution is already part of the workload. Dirty Frag should be treated as a kernel emergency for those systems.

What a good after-action review should ask

After the patch window closes, the after-action review should not stop at “we updated kernels.” Dirty Frag exposes deeper questions about how the organization handles local kernel risk.

Which systems are allowed to run untrusted code? Are they inventoried as a distinct risk tier? Are CI runners single-tenant or shared between untrusted and privileged jobs? Are container nodes that run untrusted workloads separated from nodes that hold sensitive credentials? Are user namespaces enabled by default? Are privileged pods rare and justified? Are IPsec and AFS dependencies documented before emergency mitigations are needed? Can the team query module load status across the fleet in minutes?

The same review should look at detection debt. Do you know when a non-baseline process creates AF_RXRPC sockets? Can you see unexpected NETLINK_XFRM activity? Can you detect sudden module loading by untrusted users? Can you correlate a local compiler invocation, namespace creation, module loading, and setuid binary execution? None of those signals is perfect alone, but together they turn a silent local exploit path into a visible story.

The review should also cover patch mechanics. How long does it take to rebuild a golden image? How long until Kubernetes nodes are drained and rebooted? How many systems install a kernel update but never reboot? Which livepatch products are trusted, and how is coverage verified? Dirty Frag is a kernel bug, so “package installed” is not enough. The running kernel matters.

Reference links and further reading

NVD entry for CVE-2026-43284, the published record for the xfrm ESP shared skb fragment issue. (nvd.nist.gov)

Hyunwoo Kim’s Dirty Frag public disclosure on oss-security. (openwall.com)

V4bel Dirty Frag repository and technical write-up, including affected version notes, CVE status updates, and patch discussion. (GitHub)

Red Hat security bulletin RHSB-2026-003 for Dirty Frag impact, affected Red Hat products, and OpenShift context. (레드햇 고객 포털)

AlmaLinux Dirty Frag advisory with CVE mapping and patched kernel versions for AlmaLinux streams. (AlmaLinux OS)

AWS security bulletin for Dirty Frag and related Linux kernel issues, including affected module checks and temporary mitigations. (Amazon Web Services, Inc.)

CloudLinux mitigation and kernel update advisory, including module blacklist trade-offs and page-cache cleanup notes. (blog.cloudlinux.com)

Debian security tracker for CVE-2026-43284 release-specific package status. (Security Tracker)

Linux kernel documentation for struct sk_buff, 스플라이스, RxRPC, and XFRM. (docs.kernel.org)

NVD entry for Dirty Pipe CVE-2022-0847, useful for understanding the older page-cache write family. (nvd.nist.gov)

NVD and Microsoft references for Copy Fail CVE-2026-31431, the closest recent predecessor to Dirty Frag. (nvd.nist.gov)

Penligent’s Copy Fail CVE-2026-31431 analysis, relevant to the same Linux page-cache write bug family. (penligent.ai)

Penligent homepage for authorized AI-assisted CVE scanning, vulnerability validation, and evidence-first reporting workflows. (penligent.ai)