DirtyPipe (CVE-2022-0847): Why This 3-Year-Old Linux Kernel CVE Still Hits Indian Production

Last updated: April 26, 2026

DirtyPipe (CVE-2022-0847) was disclosed in March 2022. It is a Linux kernel vulnerability allowing local privilege escalation by overwriting read-only files. The fix has been available for over three years. Yet in 2026, on roughly one in five Indian-market Linux pentests, we still find vulnerable kernels in production. This article explains the bug, the exploit, why patching has lagged, the detection that catches active exploitation, and the kernel-version baseline you should enforce.

The bug in 60 seconds

Linux pipes use a structure called pipe_buffer. Each buffer has a flags field that includes PIPE_BUF_FLAG_CAN_MERGE. A flaw in copy_page_to_iter_pipe() meant that when a page was spliced from a file (using the splice() syscall) into a pipe, this flag was inherited from a previously-used buffer instead of being initialised.

The result: an attacker could splice a page from a read-only file into a pipe, then write to the pipe — and the kernel would allow that write to propagate back into the file’s page cache, corrupting the file in memory. On read by another process, the corrupted version is served.

Affected kernels: 5.8 through 5.16.10, 5.15.24, 5.10.101 (specific patch versions). Anything pre-5.8 is not affected.

The exploit

The original PoC by Max Kellermann (poc.c) overwrites /etc/passwd to insert a root account with a known password:

./poc /etc/passwd 1 'root:$1$abcdef$abcdefghijklmnopqrstuv:0:0:root:/root:/bin/bash\\n'

From a low-privilege shell, this gives a root account in seconds. No file write to disk is needed at first; the page cache is corrupted, and any process reading /etc/passwd sees the malicious version.

For more flexible exploitation, Phith0n’s PoC overwrites SUID binaries — a SUID /usr/bin/su can be patched in memory to run arbitrary code, then invoking su gives root.

Why this still works in 2026

Kernel patching on Linux is not automatic in production. Servers that run mission-critical workloads are routinely:

• Stuck on the kernel version that shipped with the distribution release (RHEL 8, Ubuntu 20.04, etc.) without backported security fixes if they are not on the paid support tier.
• Running custom kernels for vendor compliance (database appliances, network gateways).
• Inside containers where the host kernel is invisible to application teams who do not realise they share it.
• In change-controlled environments where any reboot requires multi-week approval.
• Operating on the assumption “we patched everything in 2022” — without verifying the actual kernel version.

We routinely find kernels like 5.10.45 (Ubuntu 20.04 with default updates, missing 5.10.102) on production RDS-equivalent boxes, ML training servers, and self-managed Kubernetes nodes.

Detection — what works

Static detection of an unpatched kernel is straightforward. Run on every Linux host:

uname -r
# Compare against patched versions:
# 5.10.102+, 5.15.25+, 5.16.11+ are patched

# Or use distro-specific tools:
# RHEL/CentOS:
rpm -q kernel | grep -i <version>
# Debian/Ubuntu:
dpkg -l | grep linux-image

For runtime detection of exploitation:

• Auditd rules on file integrity for /etc/passwd, /etc/shadow, SUID binaries — any unexpected modification fires.
• Falco rules — community rule for Dirty Pipe detects the splice + write pattern at runtime.
• EDR with Linux coverage — most flag the exploit by behavioural pattern.
• Pipe inspection via eBPF — production uncommon but most reliable; used by some commercial Linux EDRs.

Mitigation

The only fix is to patch the kernel. Workarounds (mount options, SELinux policy, app-level controls) do not close the bug — the splice operation happens in the kernel, below those layers.

Patched kernel versions:

• Linux 5.10.102+
• Linux 5.15.25+
• Linux 5.16.11+
• Latest distro kernels include the fix

If you cannot reboot in the short term, options are:

• Live patching — kpatch (RHEL), kgraft, Ubuntu Livepatch, Oracle Ksplice. Apply the patch without reboot. Available on enterprise distros with paid support.
• Strict access controls — limit who can run code on the box. If only trusted operators have shell, exploitation requires a separate compromise first. Not a fix; a stalling tactic.
• Reboot — schedule the reboot. The bug is local-privilege-escalation; if your environment is exposed, this is a P1 ticket.

How to think about kernel CVEs

Kernel CVEs come up several times a year. Most are local privilege escalation, requiring an attacker to first have a foothold. The argument “we have perimeter defences” is incomplete — every Linux server worth attacking has at least one webhook handler, log aggregator, or monitoring agent that has had a vulnerability disclosed in its history. Combined kill-chain: external CVE in a network service for initial access, kernel CVE for privilege escalation. Defenders need both halves patched.

The discipline you actually need:

• Inventory. A complete list of every Linux host, kernel version, last reboot date.
• SLA. Critical kernel CVEs (LPE rated 7+) get patched in 30 days. High in 60. Enforced via tickets.
• Live patching for systems that cannot reboot frequently.
• Container hosts — the kernel is shared by every container. Patch the host; patch the orchestrator’s nodes.
• Cloud workloads — auto-rolling node groups (managed Kubernetes services, AWS Auto Scaling Groups) make patching less painful. Use them.

Beyond DirtyPipe — the kernel CVE roster you should track

Other recent Linux kernel privilege-escalation CVEs that hit Indian production environments routinely:

• CVE-2021-4034 (PwnKit) — Polkit pkexec, not strictly kernel but exploited similarly. Local root via SUID-root binary.
• CVE-2022-2588 (Stack Rot) — kernel race condition.
• CVE-2023-32233 (StackRot continuation) — Netfilter use-after-free.
• CVE-2024-1086 (nf_tables) — Netfilter local privilege escalation, widely reported in early 2024.
• Various io_uring CVEs — multiple disclosures since 2022; worth disabling io_uring in production if not used.

Subscribe to oss-security mailing list, the Linux Kernel CVE feed, and your distribution’s security advisories. Patch on the SLA you committed to.

How to find your next kernel-CVE exposure

For attackers (legitimate red-team):

• Run linux-exploit-suggester.sh on every compromised host. It cross-references kernel version against known exploits.
• Use linpeas + LinEnum for full PrivEsc enumeration; kernel CVE matches are highlighted.
• Test container escape paths — DirtyPipe is exploitable from inside containers if the host kernel is vulnerable.

For defenders:

• Run kube-bench against Kubernetes clusters; flag unpatched node kernels.
• Use Tenable / Qualys / Rapid7 with credentialed scans against Linux fleet.
• Build a CMDB-style inventory of kernel versions and last-reboot dates.

Compliance angle

• RBI Cyber Framework — patch SLA expectations are explicit.
• SEBI CSCRF — vulnerability management is a control family with documented cadence requirements.
• DPDP §8(5) — known-CVE production systems processing personal data fail reasonable-security tests.
• ISO 27001:2022 A.8.8 — management of technical vulnerabilities.

The takeaway

DirtyPipe is a 2022 vulnerability that should be a 2022 problem. It is a 2026 problem because Linux patching at organisational scale is harder than it looks. The fix is patching discipline, not technology. If you have not run uname -r across your Linux fleet this quarter and confirmed every host is on a patched kernel, you have unmitigated DirtyPipe exposure right now. The remediation is either a reboot or live patching. Both are cheaper than the breach.