# DF-4907 — dm_target_delay async-drain use-after-free (verified)

## Finding
`_destroy()` in `sys/dev/disk/dm/delay/dm_target_delay.c:341` drains the delay
queue with `_submit_queue(di, 1)`, which **asynchronously** submits every queued
bio to the underlying pdev via `vn_strategy()` (`_submit`, :267) and returns
immediately. Nothing in the target (or in the dm core teardown that follows)
waits for those bios to complete, yet their completion path dereferences memory
owned by the dm device that is about to be freed:

* the bios are nestbufs created by `dmstrategy()`
  (`sys/dev/disk/dm/device-mapper.c:425`) whose
  `bio_caller_info2.ptr = &dmv->stats` was captured at strategy time;
* when the pdev driver finally completes them,
  `nestiobuf_iodone()` → `nestiobuf_done(..., stats)`
  (`sys/kern/vfs_bio.c:4505`) → `devstat_end_transaction()`
  (`sys/kern/subr_devstat.c:179`) **writes** `last_comp_time`,
  `busy_count--`, `bytes_read += n`, `num_reads++` through that stale pointer;
* by then `dm_table_destroy` → `dm_target_delay_destroy` has returned and
  `dm_dev_destroy` → `dm_dev_free` (`sys/dev/disk/dm/dm_dev.c:384`) has
  **kfree()d the dm_dev** that embeds that devstat.

For the linear target the same window exists but is only as wide as one disk
latency; the delay target makes it *hostile-friendly*: it (a) holds bios long
past strategy() return and (b) dumps the whole queue at destroy time, so the
freed-memory window can be widened to **seconds** by stacking delay targets
(the PoC stacks `d2(delay) ← d1(delay, removed) ← d0(delay) ← vn0`, giving a
~1 s gap between `dm_dev_free(dmv1)` and the completion of d1's orphaned bios).

## Reproduction (baseline, stock module) — REPRODUCED 2/2 from fresh boots
Guest: DragonFly 6.5-DEVELOPMENT (#0 Jul 2 2026) X86_64_GENERIC, QEMU/KVM.
Per-iteration (see df4907.c for the full timeline):
1. `d0 = delay(/dev/vn0, 1000ms)`, `d1 = delay(/dev/mapper/d0, 1000ms)`,
   `d2 = delay(/dev/mapper/d1, 1000ms)`.
2. 48 reader threads `pread()` /dev/mapper/d2 → bios queue in d2 (1 s).
3. t0+1.0 they hop into **d1's** queue (nestbufs with `stats=&dmv1->stats`).
4. t0+1.2 `dmsetup suspend d2; reload d2 (table on vn0); resume d2` —
   resume destroys d2's OLD table → delay `_destroy` → `dm_pdev_decr` →
   `vn_close(d1)` → `dmclose(d1)` → `d1.is_open = 0` (release from pdev-hold;
   d2's own fds stay held by the blocked readers, so d2 cannot be removed but
   d1 can).
5. `dmsetup remove d1` → `_submit_queue(di,1)` submits the queued bios into
   **d0's** 1 s queue and returns; teardown frees dmv1 (~µs later).
6. Spray `dmsetup create f0..f7` → the freed dm_dev chunk is immediately
   reallocated as live device **f0**.
7. t0+2.2 d0's timer fires, the orphaned bios complete on vn0, and
   `devstat_end_transaction` writes into the **live f0 device's** devstat.

Observed on the serial console (identical both runs):
```
devstat_end_transaction: HELP!! busy_count for f00 is < 0 (-1)!
panic: bio_track_rel: bad count: 0xfffff8008da31610
Trace beginning at frame ...
biodone() at biodone+0x17b
biodone() at biodone+0x17b
vnstrategy() at vnstrategy+0x125
dev_dstrategy() at dev_dstrategy+0xf5
diskstrategy() at diskstrategy+0x3b
dev_dstrategy_chain() at dev_dstrategy_chain+0x8b
Debugger("panic")
```
`HELP!! busy_count for f00` is the smoking gun: the late completion
decremented the devstat of **f0 — a different, live device** that happened to
realloc the freed chunk — i.e. a demonstrated cross-object write-after-free
into a reallocated kernel heap object, followed by secondary corruption and a
`bio_track_rel` panic in biodone.

Files: panic.txt (run 1), panic.2.baseline.txt (run 2, fresh boot),
run.log (ssh capture; connection died when the box panicked).

## Fix validation — FIXED
`fix.diff` changes the `submit_all` path of `_submit_queue` to fail the queued
bios (`b_error = ENXIO; b_resid = b_bcount; biodone(&bp->b_bio1)`) instead of
asynchronously submitting them past the target's lifetime. Built
`sys/dev/disk/dm/delay/dm_target_delay.c` as a module in the guest
(`make obj; make` in /usr/src/sys/dev/disk/dm/delay), loaded the patched
`dm_target_delay_fixed.ko`, and re-ran the exact PoC:
* 2 iterations x 48 readers: `RC=0 HELP_before=0 HELP_after=0`, guest up.
* 5 iterations x 96 readers (stress): clean, guest up, `dmesg` free of HELP.
Baseline stock module: panic on both runs. Patched: no panic, no HELP, no
leak of the corruption signature — bad behavior gone. (fix_build.log /
fix_run.log hold the untrimmed logs.)

Note on semantics: erroring queued I/O during target teardown also affects the
table-reload case (resume destroying an old table with queued bios); those
reads now see ENXIO instead of being submitted. That matches the
"device/table disappearing under I/O" contract userspace already has to
tolerate and is the safe default until the dm core gains per-bio lifetime
refcounting (the deeper fix, out of scope for this file).

## Threat model
Reaching this requires the device-mapper control device (/dev/mapper/control,
root-only), i.e. local root (or a jail/namespace given it). It is therefore
not an unpriv→root escalator by itself, but it turns an ordinary
create/destroy admin sequence into deterministic kernel heap corruption with
an attacker-chosen reallocation victim and repeated semi-controlled writes
(`bytes_read += b_bcount`, `num_reads++`, timestamps) — usable for
kernel-state corruption / DoS in the same class as the other verified dm
teardown bugs this cycle (DF-4900 family).

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.