Intro

This blog post reflects our exploration of the Dirty Pipe Vulnerability in the Linux kernel. The bug was discovered by Max Kellermann and described here . If you haven’t read the original publication yet, we’d suggest that you read it first (maybe also twice ;)). While Kellermann’s post is a great resource that contains all the relevant information to understand the bug, it assumes some familiarity with the Linux kernel. To fully understand what’s going on we’d like to shed some light on specific kernel internals. The aim of this post is to share our knowledge and to provide a resource for other interested individuals. The idea of this post is as follows: We take a small proof-of-concept (PoC) program and divide it into several stages. Each stage issues a system call (or syscall for short), and we will look inside the kernel to understand which actions and state changes occur in response to those calls. For this we use both, the kernel source code (elixir.bootlin.com , version 5.17.9) and a kernel debugging setup (derived from linux-kernel-debugging ). The Dirty Pipe-specific debugging setup and the PoC code is provided in a GitHub repository.

In this blog post I will go in depth into the inner workings of CVE-2021-43247 , which was fixed on the 14th of December 2021. This bug was classified as “Windows TCP/IP Driver Elevation of Privilege Vulnerability”. The vulnerability itself was probably dormant for a long time, but became exploitable when the AF_UNIX address family was first introduced in 2019.

I will also take this as an excuse to explain in detail, what drivers are, how user space communicates with drivers, what a Local Privilege Escalation (LPE) is and what how we can achieve it in this case.