Dirty Pipe Explained | Hacker News Reader

Dirty Pipe Explained

hackthebox.com

78 pointsgtzi13 comments

> pipe flag “PIPE_BUF_FLAG_CAN_MERGE”, which signifies that the data buffer inside the pipe can be merged, i.e, this flag notifies the kernel that the changes which are written to the page cache pointed to by the pipe shall be written back to the file

That's not what this flag does. No pipe flag can ever cause writing dirty pages back to disk, because pipes have by definition nothing to do with files.

The CAN_MERGE flag tells the kernel that the next write() to the pipe can append data to this pipe buffer until it's full, instead of creating a new pipe buffer for every write().

I stopped reading when it starts explaining what's memory management.

In contrast I found the explanation written by the original author an engaging read: https://dirtypipe.cm4all.com/

That was a very interesting read for sure.

This part was especially eye-opening:

"... it not only works without write permissions, it also works with immutable files, on read-only btrfs snapshots and on read-only mounts (including CD-ROM mounts)..."

Discussion last month:

https://news.ycombinator.com/item?id=30586740

Thanks for this reference, I found the timeline interesting, especially the initial report in 2021, then the one month sequence and timeframe in 2022.

Took a long while until I found the right state of mind to finally understand what was causing those (rare) file corruptions. Once I figured that out, the rest was easy :-)

I really resonated with the assumption which was wrong and moments of exhausted ideas. Thank you for documenting these.

I never knew that the standard command pipe is an “anonymous pipe”, but now “named pipes” make more sense.

There's also "anonymous memory" (as opposed to memory mapped from a file, which you could call "named memory").

I guess hardware RWX permissions on disks would be useful for this sort of thing.

Not really, since corrupting the page cache is (in many cases) equivalent to corrupting the data on disk. You could try to enforce RWX on page cache pages, but then the cache manager would have to flip the W flag really frequently and that could reduce performance (TLB invalidation, etc)

Apple had to do custom stuff in various parts of their stack to make it cheap to flip the W and X flags since they wanted to do it frequently.

Yeah, like 30 seconds after I wrote that I was lying in bed and thinking "nope, that's not gonna do shit".

No, the disk is not involved in this vulnerability. It happens only in RAM (the page cache).

Reply on news.ycombinator.com