# DF-2903 VERDICT

**Status: reproduced — impact: panic (guaranteed kernel panic from one
crafted MBR sector; DoS class).**

## How it reproduced
1. 32 KB image: MBR magic 0x55AA at offset 510, partition entry[0] type
   0x54 (DOSPTYP_ONTRACK) at offset 450 (mkontrack.py).  Same table also
   placed at LBA 63 for the re-read leg.
2. `vnconfig -c -v -S 512 vn0 /root/ontrack.img` on the stock INVARIANTS
   guest → **immediate panic**, serial console (panic.txt):
   `panic: brelse: inappropriate B_PAGING or B_CLUSTER` with the exact
   stack `brelse ← mbrinit ← disk_probe ← disk_msg_core`.  The synchronous
   probe (`disk_setdiskinfo_sync`, vn.c:584/869) runs mbrinit in the disk
   core thread; the Ontrack branch (subr_diskmbr.c:178-179) calls
   `brelse()` on the `getpbuf_mem()` pbuf from :127.
3. Post-panic the guest was catatonic (`vm.sh status` → down; new ssh
   connections timed out during banner exchange).

## Reachability
* USB mass-storage plug-in: CAM auto-probes as root — no user action
  needed beyond physical insertion of crafted media.
* Boot with an Ontrack-managed disk (0x54 was a real-world Disk Manager
  convention, still honored here).
* Root `vnconfig` (used for the PoC).

## Non-INVARIANTS behavior (reasoned, not run)
`KASSERT` compiles out; `brelse()` then inserts the B_PAGING pbuf into
buffer-cache queues (vfs_bio.c:1268+): one pbuf leaked from
`bswlist_mem` per Ontrack attach (cross-subsystem lifecycle corruption;
replug loop → `getpbuf_mem()` exhaustion → permanent paging/probe wedge).
The primary, demonstrated impact is the INVARIANTS panic.

## Fix validation (this run)
fix.diff hunk 2: `relpbuf(bp, NULL)` + one-shot re-read guard
(`mbr_offset == DOSBBSECTOR`).  Patched kernel (built in-guest with
`make nativekernel`): `vnconfig` of ontrack.img completes cleanly, slices
are created, guest stays up (run_fix.log).  Baseline panic vs patched
clean-attach recorded side by side in this pack.