dirty_cow: fix false-EXPLOIT_OK (same 3 bugs as dirty_pipe) + audit the corpus

False-EXPLOIT_OK audit: the dispatcher's run_callback_isolated reports OK when the
exploit execve()s (FD_CLOEXEC closes the result pipe -> parent reads EOF), so any
exploit whose main path execs a not-guaranteed-root target lies. Audited every
exec*-calling module (results in docs/EXPLOITED.md).

dirty_cow had the identical 3-bug pattern to the pre-fix dirty_pipe:
  1. raced the CALLER's UID field to "0000" then ran `su self` -> still needs the
     caller's password, never rooted anything;
  2. execlp'd su -> dispatcher's exec-transfer path reported a FALSE EXPLOIT_OK;
  3. reverted via drop_caches (needs root) -> left the running /etc/passwd
     corrupted when run unprivileged.
Plus a latent overflow: the success-check readback[16] was too small for a
payload > 16 bytes.

Fix (byte-for-byte the verified dirty_pipe technique): race ROOT's password field
to a known $6$ hash -> authenticate as root over a pty -> plant a root-owned proof
+ setuid bash -> revert by racing the original bytes back through the Dirty COW
primitive (no root / no drop_caches). Success judged only by the OOB artifact;
readback buffer bumped to 512. cleanup() re-reverts idempotently.

The escalation half is identical to dirty_pipe (verified end-to-end); the COW
primitive itself needs a pre-4.8.3 kernel to land, which no cached VM has, so on
patched hosts it now fails HONESTLY with no corruption. Unit harness green.

Other exec-transfer modules audited clean or already-fixed; two (overlayfs proxy,
sudoedit_editor unverified reporting) noted for tightening.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y

docs/EXPLOITED.md

@@ -114,6 +114,18 @@ tamper check).
   Dirty Pipe primitive itself** (write the saved original bytes back — no root, no
   drop_caches). Verified `/etc/passwd` is byte-identical afterward. Root judged
   only by the out-of-band artifact.
+- **`dirty_cow`** (CVE-2016-5195) — **same three bugs as `dirty_pipe`, fixed the
+  same way** (found by the false-`EXPLOIT_OK` audit below). It raced the
+  *caller's* UID field to `0000` then ran `su self` (needs the caller's password
+  → never rooted anything), `execlp`'d su so the exec-transfer path reported a
+  **false `EXPLOIT_OK`**, and reverted with `drop_caches` (needs root → corrupts
+  the running /etc/passwd). Rewrote to: race **root's** password field to a known
+  `$6$` hash → authenticate as root over a pty → plant a root-owned proof + setuid
+  bash → revert by racing the original bytes back through the Dirty COW primitive.
+  Also fixed a latent buffer overflow (the success-check `readback[16]` was too
+  small for a >16-byte payload). The escalation half is byte-for-byte the verified
+  `dirty_pipe` technique; end-to-end root here needs a pre-4.8.3 kernel (every
+  cached VM is patched), so on those it now fails **honestly** with no corruption.
 - **`cgroup_release_agent`** — two real bugs fixed (commit `8c45b2b`): it read
   `getuid()` **after** `unshare(CLONE_NEWUSER)` (→ `65534`, so `uid_map` write
   was `"0 65534 1"` → EPERM), and it omitted `CLONE_NEWCGROUP` (→ cgroup-v1
@@ -125,6 +137,35 @@ tamper check).
   container" framing. The `getuid()`-after-`unshare` bug is a pattern to grep
   for across the other userns modules.
 
+## False-`EXPLOIT_OK` audit (every module that transfers the process via `exec*`)
+
+The dispatcher's `run_callback_isolated` forks the exploit and, if it `execve`s
+(FD_CLOEXEC closes the result pipe → parent reads EOF, no crash signal), reports
+`EXPLOIT_OK` **regardless of whether the exec'd program actually rooted anything**.
+So any exploit whose main path exec's a *not-guaranteed-root* target lies. Audited
+every `exec*`-calling module:
+
+| module | verdict | why |
+|---|---|---|
+| `dirty_cow` | ❌ **false-OK → fixed** | raced own UID + `su self`; `execlp(su)` transfer = OK. Fixed (see above). |
+| `pwnkit` | ✅ fixed earlier | now re-injects gconv + verifies |
+| `ptrace_traceme` | ✅ fixed earlier | rewritten; verifies OOB artifact |
+| `dirty_pipe` | ✅ fixed earlier | rewritten; verifies OOB artifact |
+| `sudo_host` | ✅ safe | runs `sudo -n -h <host> id -u` witness (uid 0) *before* the exec |
+| `sudo_chwoot` | ✅ safe | forks sudo in a child, then `stat`s the setuid bash root-owned |
+| `cgroup_release_agent` | ✅ safe | polls for the root-owned setuid shell before exec |
+| `fuse_legacy` | ✅ honest | gates the exec on real `setuid(0)==0 && getuid()==0`; else `EXPLOIT_FAIL` |
+| `overlayfs` | ⚠️ proxy (low risk) | confirms the `security.capability` xattr persisted via `getxattr` before exec'ing the cap'd payload — strong proxy, works, but not a direct root witness |
+| `sudoedit_editor` | ⚠️ works, reporting unverified | plants a passwordless `skel:0:0` entry + `su skel` (confirmed to root), but returns `EXPLOIT_OK` unconditionally — would false-OK if su failed |
+| `dirtydecrypt`, `fragnesia` | ⚠️ 2026 reconstructed | exec the target only after verifying the payload landed in the page cache (`rc==1` / `WEXITSTATUS==0`) — proxy, not direct witness; neither lands on any available target yet |
+| `ptrace_pidfd` | ✅ n/a | the `execve` is the *victim* being raced (fd-steal), not an escalation |
+| `mutagen_astronomy` | ✅ n/a | env-gated scaffold; SIGSEGVs by design |
+
+Net: the exec-transfer trap produced **four** genuine false-OKs (`pwnkit`,
+`ptrace_traceme`, `dirty_pipe`, `dirty_cow`) — all now fixed. Two ⚠️ items
+(`overlayfs` proxy, `sudoedit_editor` unverified reporting) work but could be
+tightened to a direct out-of-band witness.
+
 ## Needs a faithful PoC port (genuinely vulnerable target, exploit doesn't land)
 
 | module | CVE | target tested | what's wrong |