Dirty Pipe Linux kernel arbitrary write (CVE-2022-0847)

CVE-2022-0847, nicknamed "Dirty Pipe," is a local privilege-escalation vulnerability in the Linux kernel that lets an unprivileged, low-privilege user overwrite data in arbitrary read-only files — including files they don't have write permission to — by abusing a flaw in how the kernel's pipe buffer mechanism handles page cache pages. The practical impact is severe: an attacker with any local code execution, even inside a restricted container or a web shell running as a low-privilege service account, can rewrite SUID binaries, inject a root shell into /etc/passwd, or tamper with cron scripts to escalate to full root. Because exploitation requires no special capabilities, no race-condition timing tricks, and works reliably in a handful of milliseconds, Dirty Pipe quickly became one of the most weaponized Linux kernel bugs since Dirty COW (CVE-2016-5195), to which it is often compared and which it significantly improves on from an attacker's perspective — it is simpler, faster, and considerably more reliable.

What Went Wrong

The vulnerability lives in the kernel's splice() and pipe-buffer handling code. Linux pipes are backed by a ring of struct pipe_buffer objects, and each buffer carries a PIPE_BUF_FLAG_CAN_MERGE flag that tells the kernel it's safe to append more data to an existing buffer rather than allocating a new one, as an optimization. The bug is that when data is spliced from a read-only file into a pipe, the kernel initializes a new pipe buffer that references the file's page cache page directly, but does not properly clear the "can merge" flag on that buffer. An attacker can then use a regular, unprivileged write() call to the pipe to inject content directly into that referenced page cache page — the very page holding the on-disk file's contents in memory — even though the underlying file itself was opened read-only. The kernel's normal permission checks are for the write into the pipe, not for the actual page being modified, so the copy-on-write and permission model that should protect read-only files is bypassed entirely. The result is arbitrary-offset, arbitrary-content overwrite of any file the attacker can read, with no ownership or write permission needed on that file.

Affected Versions and Components

Dirty Pipe affects the Linux kernel from version 5.8 up through fixed releases. The bug was introduced when the pipe buffer "merge" optimization was reworked, and it persisted for roughly a year and a half before discovery. Because so many enterprise and cloud distributions track upstream stable kernels closely, the exposure surface is broad:

• Mainline Linux kernel 5.8 through 5.16.10
• Linux kernel 5.15 branch prior to 5.15.25
• Linux kernel 5.10 branch prior to 5.10.102
• Kernel versions earlier than 5.8 are not affected, since they lack the reworked pipe buffer code path
• Android devices running affected kernel versions (the bug is reachable from unprivileged app sandboxes on many Android builds, and public one-click root exploits for several device models were released within days of disclosure)
• Any container host, Kubernetes node, or VM whose underlying kernel falls in the affected range — container namespace isolation does not stop this bug, since it's a kernel memory-management flaw, not a namespace or cgroup issue

Distributions that back-port fixes independently of upstream version numbers (Ubuntu, RHEL/CentOS derivatives, Debian, SUSE, Amazon Linux, etc.) each shipped their own patched kernel builds; teams should check patch level against vendor advisories rather than relying on raw kernel version numbers alone.

CVSS, EPSS, and Exploitation Context

CVE-2022-0847 carries a CVSS v3.1 base score of 7.8 (High), reflecting local attack vector, low attack complexity, low privileges required, no user interaction, and high impact to confidentiality, integrity, and availability once escalation succeeds. The "low privileges required, no user interaction" combination is what makes this more dangerous in practice than the score alone suggests: any foothold — a compromised web application, an SSRF-to-RCE chain, a malicious npm postinstall script, a container escape attempt, or a rogue insider process — becomes a direct path to root.

EPSS scoring for Dirty Pipe has consistently sat well above the median for scored CVEs, driven by the combination of a public, reliable, weaponized proof-of-concept and its applicability across an enormous population of Linux hosts and Android devices. Reliable root-in-seconds exploits were public within a week of disclosure, which is unusually fast even by modern vulnerability-research standards, and that speed is reflected in sustained exploitation interest from red teams, malware authors, and CTF/security-research communities alike. Whether or not a given CVE sits on CISA's Known Exploited Vulnerabilities catalog at any point in time, security teams should treat any Linux LPE with a public one-shot exploit and this breadth of affected infrastructure as functionally equivalent to a KEV-listed flaw for prioritization purposes — the absence of a KEV entry is not evidence of low real-world risk.

Timeline

• February 19, 2022 — Security researcher Max Kellermann (CM4all/IONOS) discovers the flaw while investigating corrupted log files on a customer's server, traces it to the pipe buffer merge logic, and privately reports it to the Linux kernel security team.
• February 20–21, 2022 — Kellermann develops a working proof-of-concept demonstrating arbitrary write to read-only files, including overwriting SUID binaries for privilege escalation.
• February 23, 2022 — A fix lands in the mainline Linux kernel, clearing the PIPE_BUF_FLAG_CAN_MERGE flag correctly when a page cache page is spliced into a pipe buffer.
• February 24, 2022 — Patched kernel releases 5.16.11, 5.15.25, and 5.10.102 ship with the fix.
• March 7, 2022 — Full public disclosure, including a detailed technical write-up and proof-of-concept exploit, published by Kellermann; CVE-2022-0847 is formally assigned.
• March 2022 (following days/weeks) — Independent researchers publish additional exploit variants, including Android-specific root exploits for popular device models, and Linux distribution vendors ship their own back-ported kernel patches.

Remediation Steps

1. Patch the kernel first. Update to a kernel version at or beyond the fixed releases for your branch: 5.16.11+, 5.15.25+, or 5.10.102+, or the equivalent vendor-back-ported build for your distribution (check RHEL/CentOS, Ubuntu, Debian, SUSE, and Amazon Linux security advisories directly, since their internal version numbering differs from upstream).
2. Prioritize by exposure, not just presence. Multi-tenant hosts, Kubernetes worker nodes, shared build agents, and any system running untrusted or third-party code under a low-privilege account should be patched first, since those are the environments where an attacker is most likely to already have the local foothold this bug requires.
3. Patch container hosts, not just container images. Because this is a kernel-level bug, updating the base image inside a container does nothing if the underlying host kernel is still vulnerable — inventory and patch the node OS/kernel across your fleet, including managed Kubernetes node pools where kernel version is often controlled by node image selection rather than in-container package updates.
4. Patch or update mobile/embedded fleets separately. Android devices and other embedded Linux systems need vendor-specific security patches; track OEM advisories, since generic Linux kernel patching guidance won't reach these devices.
5. If immediate patching isn't possible, reduce blast radius. Restrict local code execution wherever feasible (least-privilege service accounts, seccomp/AppArmor profiles, disabling unnecessary interpreters/shells in production containers) to shrink the population of processes that could reach the vulnerable code path, and increase monitoring for anomalous writes to SUID binaries, /etc/passwd, /etc/shadow, and cron directories as a compensating detection control.
6. Verify the fix, don't assume it. After patching, confirm the running kernel version on each host matches or exceeds the fixed build — configuration drift, unapplied updates on long-lived instances, and golden images baked before the patch was available are common reasons organizations remain exposed well after a fix ships.

How Safeguard Helps

Dirty Pipe is exactly the kind of vulnerability that turns "we have an SBOM" into "we know which of our 4,000 hosts and containers actually need action tonight." Safeguard's SBOM generation and ingest pipeline maps kernel and base-image versions across your fleet — bare-metal, VM, and Kubernetes nodes alike — so you can instantly identify every asset running an affected kernel branch instead of manually cross-referencing distro advisories. Griffin AI then correlates that exposure against how each affected host is actually used, layering in reachability analysis to flag which systems expose untrusted code execution paths (shared build runners, multi-tenant workloads, internet-facing services with command-injection-prone dependencies) that meaningfully raise the odds of a local foothold being obtained in the first place. That context lets your team triage a fleet-wide kernel CVE by real risk rather than CVSS score alone, cutting through alert fatigue from vulnerabilities that are technically present but practically unreachable. Where remediation is straightforward, such as bumping a base image tag or pinning a patched kernel package in infrastructure-as-code, Safeguard's auto-fix PRs propose the exact change so engineering teams can merge and deploy the patch without a manual hunt through Dockerfiles and node pool configs. The net effect is faster time-to-patch on the hosts that matter most, with less manual triage in between.