Dirty COW CVE-2016-5195: How a 2016 Linux Kernel Race Condition Still Enables Privilege Escalation in Embedded Systems

The 2016 discovery of CVE-2016-5195, widely known as Dirty COW, revealed a race condition in the Linux kernel’s copy-on-write mechanism. The flaw enabled a local attacker to modify memory pages that should have remained read-only, providing a primitive for writing to protected files or memory regions.

Although the vulnerability was fixed in October 2016 for mainstream distributions, many embedded devices continue to run unpatched kernels for years. Routers, IP cameras, industrial controllers, and similar hardware often ship with vendor firmware that is rarely updated, leaving the original bug intact.

What Dirty COW Actually Allows

Dirty COW does not grant root privileges directly. It supplies a write primitive that can alter files such as /etc/passwd or overwrite code in memory-mapped regions. Attackers must then chain this primitive with additional steps, such as adding a root user entry or modifying a SUID binary, to achieve privilege escalation.

Public proof-of-concept code repeatedly triggers the race by writing through /proc/self/mem while calling madvise(..., MADV_DONTNEED). Correct timing causes the kernel to drop the original copy-on-write page, allowing the attacker’s data to persist in the shared mapping.

Why Ready-Made Exploits Often Fail

Many public Dirty COW exploits assume a full GNU userland with /bin/sh and conventional login utilities. On embedded systems that use BusyBox, these assumptions break. The single BusyBox binary may lack the expected applet, the required symbolic link may be absent, or the arguments passed to execve may not match the applet’s expectations.

Another common target is vDSO, a small kernel-provided library mapped into every process address space. Because vDSO exists only in memory and not as a file on disk, overwriting its functions requires precise knowledge of the architecture, the exported symbols, and the exact function chosen by the exploit. Payloads must also be written in the correct instruction set and respect the target ABI.

Practical Checks Before Exploitation

• Kernel version, build date, and presence of the Dirty COW patch
• Processor architecture, endianness, and enabled mitigations
• Available BusyBox applets and presence of login or su mechanisms
• Existence and contents of SUID binaries
• Presence and exported symbols of vDSO in process memory maps
• Compatibility of the chosen payload with the system’s libraries and shell environment

Exploitation attempts should be performed only on isolated test systems with rollback capability, as race-condition bugs can corrupt data or crash the target.

The article concludes by pointing readers to the free “White Hacker” course on the CyberED platform, where the practical lab “Strange And Dirty” requires participants to adapt a Dirty COW exploit to a minimal BusyBox environment and complete the privilege-escalation chain.