Dirty Pipe Explained: CVE-2022-0847 Linux Privilege Escalation Vulnerability

The Dirty Pipe vulnerability (CVE-2022-0847) represents a critical flaw in the Linux kernel that allowed a local, unprivileged user to escalate privileges to root.

Disclosed in March 2022 by researcher Max Kellermann, this bug enabled attackers to overwrite the content of read-only files on the system, bypassing standard file permission checks entirely.

Its significance lies in the simplicity and power of the exploit, which directly undermines the core Linux security model that isolates user permissions.

For security professionals and students, understanding Dirty Pipe provides a masterclass in kernel-level vulnerability analysis and the importance of timely patching. This analysis is intended for defensive education and technical understanding within authorized lab environments.

Vulnerability at a Glance

CVE ID	CVE-2022-0847
Vulnerability Type	Local Privilege Escalation
Affected Kernel Versions	Linux 5.8 up to 5.16.10, 5.15 up to 5.15.24, and 5.10 before 5.10.102 (commonly cited as 5.10.101)
Discovered By	Max Kellermann
Patched Versions	Linux 5.16.11, 5.15.25, and 5.10.102 (March 2022)

How the Vulnerability Works

The root cause of Dirty Pipe lies in a missing check within the kernel’s pipe buffer handling mechanism.

The kernel introduced an optimization where pipe buffers flagged with PIPE_BUF_FLAG_CAN_MERGE could be spliced and merged with a page already residing in the system’s page cache. This page cache holds frequently accessed file data for performance.

The vulnerability allowed an attacker to obtain a reference to a read-only cached page, inject it into a pipe, and then write attacker-controlled data into that pipe.

Because the pipe buffer had the merge flag set, the written data was merged directly into the cached page.

This process bypassed the normal permission checks performed when writing to the underlying file on disk, enabling the modification of any file the kernel had cached, regardless of the user’s write permissions.

Lab Walkthrough

This walkthrough simulates exploitation in a controlled, vulnerable lab environment, such as a deliberately outdated home lab setup. The goal is purely educational, demonstrating the technical steps to understand the flaw and reinforce defensive practices.

Initial Reconnaissance

We start logged into a vulnerable system as a low-privilege user (e.g., “student”). First, confirm the vulnerable kernel version.

$ uname -a
Linux labhost 5.10.101 #1 SMP ... x86_64 GNU/Linux

The kernel version 5.10.101 falls within the affected range, confirming vulnerability.

Task 1: Overwriting /etc/passwd

The classic exploitation method involves modifying the /etc/passwd file to grant root privileges to a service account. A public proof-of-concept exploit (exploit.c) requires specifying a target file, a byte offset, and the data to write.

For example, to change the UID of the “daemon” user to 0 (root), one would compile and run the exploit with the appropriate parameters.

$ gcc -o exploit exploit.c
$ ./exploit /etc/passwd [byte_offset] "substitute_data"

After a successful run, switching to the “daemon” user (e.g., su daemon) would yield a root shell. This illustrates the direct impact of arbitrary file overwrite.

Task 2: Hijacking a SUID Binary

A more sophisticated variant targets SUID-root binaries. First, locate a suitable binary like /usr/bin/sudo.

$ find / -perm -4000 -type f 2>/dev/null | head -5
/usr/bin/sudo
...

Next, compile and run a SUID-hijacking exploit (often called dirtypipez.c) against this binary.

The exploit works by splicing the binary into a pipe, modifying its content in memory to create a new SUID shell binary at a location like /tmp/sh, and then restoring the original binary to avoid immediate detection.

$ gcc -o dirtypipez dirtypipez.c
$ ./dirtypipez /usr/bin/sudo /tmp/sh
[+] Successfully overwritten /usr/bin/sudo
[+] Dropping SUID shell at /tmp/sh

Finally, execute the dropped shell to gain a root prompt.

$ /tmp/sh
# id
uid=0(root) gid=0(root) groups=0(root)...

As a good practice in any cybersecurity lab, remember to clean up the temporary SUID shell (rm -f /tmp/sh) after the demonstration.

Mitigation and Patching

The primary and definitive mitigation for Dirty Pipe is to update the Linux kernel to a patched version. All current, maintained kernel distributions have long since integrated the fix.

System administrators must ensure their systems are running Linux kernel 5.16.11, 5.15.25, 5.10.102, or any later version. Applying standard operating system updates from your distribution’s repositories is the correct action.

Most major distributions backported the patch swiftly, so even systems on long-term support (LTS) branches received updates.

As a defense-in-depth measure, limit local shell access for untrusted users and employ file integrity monitoring to detect unexpected changes to critical system files like /etc/passwd or SUID binaries.

Running services on a dedicated server with strict access controls can also help minimize the attack surface for such local exploits.

Frequently Asked Questions

Is my modern Linux system still vulnerable to Dirty Pipe?

No. The vulnerability was patched in March 2022. Any system that has received regular kernel updates since then is safe. You can verify your kernel version with the command uname -r and compare it to the patched versions listed above.

Why is it called “Dirty Pipe”?

The name is a play on the “Dirty COW” (Copy-On-Write) vulnerability. It relates to the misuse of the kernel’s pipe subsystem to perform unauthorized writes to “dirty” (modified) pages in the cache, hence “Dirty Pipe.”

Can Dirty Pipe be exploited remotely?

No. CVE-2022-0847 is strictly a local privilege escalation vulnerability. An attacker must already have some form of local user access (even low-privilege) to the target system to exploit it.

What is the main lesson for defensive security from this vulnerability?

The key takeaway is the critical importance of prompt kernel updates. It also highlights that even core, trusted kernel subsystems can contain subtle logic flaws that break fundamental security assumptions. A robust defense requires reliable infrastructure and layered security controls beyond just user permissions.

About the author