The 'Dirty' Family: Anatomy of Three Vulnerabilities That Shook Linux

Some bugs live quietly in code for years without causing harm. Others, once discovered, rewrite the history of security. The 'Dirty' family of vulnerabilities belongs firmly in the second category: they are elegant in their conceptual simplicity, devastating in impact, and deeply revealing about how a modern operating system truly works. If you're a developer who wants to understand why system-level security matters, these three cases are the perfect crash course.

Dirty COW (CVE-2016-5195): A Nine-Year Race at the Heart of the Kernel

Dirty COW was disclosed in October 2016, but the bug had existed in the Linux kernel for nearly nine years – since version 2.6.22, released in 2007. Its name comes from the mechanism it exploits: Copy-On-Write (COW), a fundamental virtual memory optimization. Its story is a perfect example of how a race condition can turn an innocent optimization feature into a privilege escalation weapon.

What Is Copy-On-Write and Why Does It Exist?

When a process creates a child process via the fork() system call, copying the entire memory space would be expensive and often unnecessary. Copy-On-Write solves this elegantly: initially, the parent and child processes share the same memory pages, marked as read-only. Only when one of them attempts to write does the kernel create a private copy of that page – hence the name. This strategy saves significant resources and speeds up process creation.

The Race Condition: When Two Steps Become Three

Dirty COW exploited a sequence of operations in the virtual memory subsystem involving two steps: first, the kernel checked whether a page could be written to (or whether a COW copy needed to be created), then it performed the write. The problem: between these two steps, another thread could intervene and discard the private copy, forcing the kernel to fall back to the original – read-only – page. By rapidly repeating this sequence in parallel, an attacker could deterministically win the race and write to memory pages they should never have accessed. The result: an unprivileged user could overwrite read-only files like /etc/passwd or setuid binaries, gaining root access. A local attacker became a system administrator in seconds.

The Patch and the Lesson

The fix was delivered by Linus Torvalds himself, just days after disclosure. The solution involved adding an additional lock in the get_user_pages() function, making the check-then-write sequence atomic – impossible to interrupt. The fundamental technical lesson: whenever you have an operation involving two separate steps (check, then act), you must ask yourself who could intervene between those two steps. This principle applies equally well in application code, not just in the kernel.

Dirty Pipe (CVE-2022-0847): When Pipe Buffers Become a Backdoor

Discovered and reported by Max Kellermann in February 2022, Dirty Pipe immediately drew comparisons to Dirty COW – and rightly so. It affected the Linux kernel from version 5.8 onwards and again allowed an unprivileged user to overwrite the contents of read-only files. But the mechanism was entirely different and, if anything, even more technically elegant.

Pipes and Splice: How Data Transfer Works in the Kernel

A Unix pipe is a unidirectional communication channel between processes. Internally, the kernel manages pipes through a set of circular buffers, each buffer associated with a memory page. The splice() system call allows data transfer directly between a file descriptor and a pipe – without copying data through userspace, an important performance optimization. Each pipe buffer has a flags field that indicates, among other things, whether the associated page can be modified or whether it is shared with other structures (for example, a file's page cache).

The Bug: An Uninitialized Flag with Severe Consequences

The problem was surprisingly simple at its root: in the function that prepared a new pipe buffer, the flags field was not properly initialized. As a result, it could inherit residual values from memory, including the PIPE_BUF_FLAG_CAN_MERGE flag – which signaled the kernel that new data could be written directly into the buffer's existing page without creating a copy. Exploitation was straightforward: an attacker created a pipe, strategically filled and drained it to manipulate the flags state, then used splice() to link a page from a read-only file's page cache to the pipe. With PIPE_BUF_FLAG_CAN_MERGE active on that buffer, subsequent writes to the pipe directly modified the cache page – the file's content – completely bypassing permission checks. SUID files, critical configurations, any readable file could be altered.

The Patch: One Line of Code That Mattered Enormously

The fix essentially ensured that the PIPE_BUF_FLAG_CAN_MERGE flag is explicitly cleared when a pipe buffer is (re)used in contexts where the page originates from outside the pipe. Minimal in size, colossal in impact. The direct lesson for any developer: always explicitly initialize variables and data structures. Residual values in memory are a constant source of subtle bugs and, sometimes, critical vulnerabilities. Never assume memory is clean.

PwnKit / Polkit (CVE-2021-4034): Twelve Years Hidden in Plain Sight

While Dirty COW and Dirty Pipe are kernel vulnerabilities, PwnKit plays in a slightly different league: it is a vulnerability in pkexec, a userspace utility that is part of Polkit (formerly PolicyKit). Discovered by the Qualys research team and disclosed in January 2022, the vulnerability had existed in pkexec since its very first version in May 2009 – meaning over twelve years during which every Linux system with Polkit installed (practically every major distribution) was exposed.

What pkexec Does and Why It Has Elevated Privileges

Polkit is an authorization framework that allows unprivileged processes to communicate with privileged processes in a controlled way. pkexec is the sudo equivalent in the Polkit ecosystem: it allows executing a program with elevated rights, after verifying authorization policies. Because it must be able to change the process identity to root, pkexec is a setuid-root binary – meaning it runs with root privileges regardless of which user launches it. This characteristic is precisely what makes it a valuable target.

The Vulnerability: Confusion Between argc and argv

The bug resided in how pkexec processed command-line arguments. Normally, argv[0] contains the program name, argv[1] the first real argument, and so on, with argc indicating the total number of arguments. The code in pkexec assumed argc is always at least 1. But on Linux, a process can be launched with argc=0 – with no arguments at all – through a specially crafted exec() call. In this situation, pkexec's code accessed argv[1] to read the first argument, but since argc was 0, argv[1] did not legitimately exist. Just beyond the boundary of the argv array lay envp – the environment variables array. By manipulating the process's environment variables, an attacker could make pkexec read and write data from a controlled location, injecting a dangerous environment variable (such as LD_PRELOAD or GCONV_PATH) that was then used by the root-privileged process to execute arbitrary code.

The Patch and the Scale of the Problem

The patch added an explicit check for argc == 0 at the beginning of pkexec's main function, treating this situation as a fatal error. Simple, direct, effective. But the scale of the impact was remarkable: Ubuntu, Debian, Fedora, CentOS, Red Hat Enterprise Linux, openSUSE – all were vulnerable. Qualys confirmed exploitability on every major distribution they tested. The fact that the bug hid for twelve years in audited open-source code is a powerful reminder that security through obscurity doesn't work – but neither does mere public code exposure guarantee that all eyes catch everything.

Transferable Lessons for Anyone Who Writes Software

The three vulnerabilities, though technically distinct, converge toward a set of principles that apply at every level of the software stack – from the kernel to the web application. Here is what every developer should take away:

The most dangerous vulnerabilities are not the most complex ones. They are those that hide in assumptions nobody questions anymore – an uninitialized flag, an array accessed without bounds checking, two steps that look like one.