Dirty Pipe — overwriting the unwritable, and putting a stop to it

02 Technical BreakdownFor engineers

So what's actually gone wrong? The root cause is an uninitialised flags member in struct pipe_buffer. When data is spliced from a file into a pipe, the kernel creates a pipe buffer that references the page cache of that file instead of copying the data (zero-copy — neat optimisation, right up until it isn't). Since commit 241699cd72a8 (Linux 4.9, 2016), the code path in copy_page_to_iter_pipe() failed to initialise the buffer's flags. That was harmless until commit f6dd975583bd (Linux 5.8, 2020) converted the mergeability check into a per-buffer flag, PIPE_BUF_FLAG_CAN_MERGE. From 5.8 onward, a stale flag could survive on a page-cache reference, letting a subsequent write() to the pipe append directly into the page cache of the spliced file — bypassing every file permission, including read-only mounts, immutable files, and SUID binaries. Oof.

Exploitation is fully deterministic — no races, no luck involved. The attacker creates a pipe, fills and drains it to stamp PIPE_BUF_FLAG_CAN_MERGE onto every ring slot, splices one byte from the target file (opened read-only) just before the target offset, then writes attacker-controlled bytes into the pipe. Those bytes land in the page cache, not the pipe. There are practical constraints: the attacker needs read permission on the target file, the write cannot start on a page boundary, cannot cross a page boundary, and cannot grow the file. That is, unfortunately, more than enough — the public PoCs overwrite entries in /etc/passwd or inject code into a SUID binary like /usr/bin/su, yielding a root shell. One subtlety that matters for forensics: the overwrite does not mark the page dirty, so it may never hit disk — the change is in-memory until something else dirties the file, and can vanish on reboot. Do not assume a clean-looking file on disk means the system was not exploited.

The vulnerable range is Linux 5.8 through 5.16.10, fixed upstream in 5.16.11, 5.15.25, and 5.10.102 by initialising the flags field on every new pipe buffer (Max Kellermann's patch). Distros backported that one-line fix into their own kernel packages. The precondition is local code execution — but note that includes any process inside a container on the host, since containers share the kernel. There is no meaningful configuration mitigation here; the only fix is a patched kernel.