DF-4895 — vinum complete_raid5_write(): second-phase RAID-5 I/O launched via vn_strategy(drive->vp) on a teardown-vulnerable vnode — deterministic NULL-vp panic (fatal trap 12 in vn_strategy), closed-vnode UAF in the mid-flight window

What this proves

complete_raid5_write() (sys/dev/raid/vinum/vinuminterrupt.c) launches the second phase of a RAID-4/5 group write (data blocks at :427, parity block at :464) with vn_strategy(drive->vp, ...). The first phase launches the same requests through dev_dstrategy(bio_driver_info=cdev, ...) (vinumrequest.c:436) — the cdev survives drive teardown, the vnode does not: set_drive_state(down) queues daemonrq_closedrive, and the vinum daemon runs close_locked_drive() → vn_close(drive->vp); drive->vp=NULL (vinumio.c:225-227) with no synchronization against the completion path. Any group write whose subdisks' states say "up" then faults in vn_strategy (vp->v_flag deref, vfs_bio.c:3375).

Teardown routes that leave/NULL the vp while writes continue: - complete_rqe()'s own ENXIO branch (vinuminterrupt.c:129-139) force-downs the drive and, in the same call, proceeds into complete_raid5_write() which launches more vn_strategy()s — racing the daemon's vn_close() (closed-vnode use-after-close / memory corruption window); - vinum stop -f <drive> (the only CLI route to real set_drive_state with force; plain setstate -f down pokes DRIVE[].state directly via setstate_by_force() and never closes anything); - post-stop state-poke recovery (vinum setstate -f up ...), which is the sequence the DF-4714/DF-4482 packs used for years on this guest.

Reproduced (deterministic, no fault injection)

1. sh ./setup_vinum.sh — 2 md drives, 3-sd RAID-5 volume rv, sanity 32KB roundtrip OK (proves vp path works when up).
2. vinum stop -f d2 — real down: daemon vn_closes vp, sds cascade crashed (dmesg shows the state cascade).
3. sleep 3
4. vinum setstate -f up d2; vinum setstate -f up rv.p0.s0 rv.p0.s1 rv.p0.s2 rv.p0 rv — states "up", vp still NULL.
5. dd of=/dev/vinum/vol/rv bs=32768 seek=5 count=1 if=/tmp/cc conv=notrunc

Result: fatal trap 12, Stopped at vn_strategy+0x38: testb $0x40,0x5c(%r13), fault address 0x5c (NULL vp + offset), current process = dd. See panic.txt (serial console), run.log (transcript+analysis).

Impact ceiling: privileged local DoS (guaranteed panic) via the deterministic route; vnode use-after-close (memory corruption potential) via the mid-flight/ENXIO route. Requires vinum administrative control (root) or a genuine component ENXIO failure → severity Medium.

Fix

fix.diff: use the cdev the code already stores in bio_driver_info at :404/:440 — dev_dstrategy(rqe->b.b_bio1.bio_driver_info, &rqe->b.b_bio1) at both sites, identical to the first-phase launch mechanism.

Fix validation: vm.sh reset with-src, apply fix.diff in guest /usr/src, make quickkernel + installkernel, reboot, re-run the exact trigger (steps 1-5): write must NOT panic (baseline panicked 1/1). See run.patched.log, fix_build.log.

Related

sdio() (vinumrequest.c:980) uses the same vn_strategy(drive->vp) pattern for raw-subdisk I/O and needs the same fix (different file).

DF-4895 — complete_raid5_write() launches RAID-5 second-phase I/O via vn_strategy(drive->vp) with no validity guarantee on the vnode

ROOT CAUSE (sys/dev/raid/vinum/vinuminterrupt.c) * :427 vn_strategy(drive->vp, &rqe->b.b_bio1); (second-phase data write) * :464 vn_strategy(drive->vp, &rqe->b.b_bio1); (parity write) The first phase launches the very same requests via dev_dstrategy(rqe->b.b_bio1.bio_driver_info, ...) with the cdev (vinumrequest.c:436, bio_driver_info = DRIVE[].dev set in build_rq_buffer vinumrequest.c:828 and re-set at vinuminterrupt.c:404/440). The cdev stays valid across vinum's drive teardown; the vnode does not: set_drive_state(down) queues daemonrq_closedrive (vinumstate.c:87-89) and the vinum daemon runs close_locked_drive() -> vn_close(drive->vp); drive->vp = NULL (vinumio.c:225-227) with no synchronization against the request completion path. Any group write that was built while the drive was up (or whose states were administratively restored) then faults: vn_strategy() dereferences vp immediately (vfs_bio.c:3368/3375).

Teardown can be triggered by: - complete_rqe()'s own ENXIO error branch (vinuminterrupt.c:129-139) force-downs the drive and then, IN THE SAME CALL, continues into complete_raid5_write() which launches more vn_strategy()s (race vs the daemon's vn_close -> closed-vnode use, or NULL deref); - administrative vinum stop -f <drive> racing in-flight group writes; - state-poke recovery (vinum setstate -f up) after a stop, which restores drive/sd/plex states without re-opening vp.

GUEST REPRODUCTION (deterministic, no fault injection needed) 1. sh setup_vinum.sh (2 md drives, 3-sd RAID-5 "rv", 2 sds on d2) 2. vinum stop -f d2 (real set_drive_state down: daemon vn_close's vp; sds cascade to crashed) 3. sleep 3 4. vinum setstate -f up d2; vinum setstate -f up rv.p0.s0 rv.p0.s1 \ rv.p0.s2 rv.p0 rv (state pokes; vp stays NULL) 5. dd of=/dev/vinum/vol/rv bs=32768 seek=5 count=1 (single group write)

Expected (unpatched): first-phase reads complete via the still-valid cdev, then complete_raid5_write() calls vn_strategy(NULL): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x5c Stopped at vn_strategy+0x38: testb $0x40,0x5c(%r13) (vfs_bio.c:3375 (vp->v_flag & VKVABIO) == 0 — NULL vp deref.)

Observed on guest DragonFly 6.5-DEVELOPMENT (x86_64), 2026-09-24: see panic.txt (full serial-console capture), run.log (session transcript).

IMPACT Privileged local kernel DoS (guaranteed panic) once vp is torn down or raced; the mid-flight variant (vn_strategy on a vnode concurrently vn_close'd by the daemon) is a vnode use-after-close -> potential memory corruption. Trigger requires vinum administrative control (root) or a genuine component ENXIO failure, hence severity Medium.

FIX (fix.diff) Launch the second phase exactly like the first phase — via the cdev the code already stores in bio_driver_info at :404/:440: - vn_strategy(drive->vp, &rqe->b.b_bio1); + dev_dstrategy(rqe->b.b_bio1.bio_driver_info, &rqe->b.b_bio1); (both sites). dev_dstrategy() on DRIVE[].dev is the proven first-phase mechanism and is unaffected by drive->vp teardown. NOTE: sdio() in vinumrequest.c:980 uses the same vn_strategy(drive->vp) pattern and needs the same treatment (out of scope for this diff).

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.