# DF-4721 — vinum launch_requests() walks the freed request group when the last group element is a skipped XFR_BAD_SUBDISK rqe and the drive completes inline (md) → kernel panic

## What this proves

The DESIGNED degraded RAID-5 write (ONE down data subdisk — no reborn
trickery, no revive, no waitlist) builds the request group as

```
rqe[0] = parity read                 (launched)
rqe[1] = good data block             (launched)
rqe[2] = down data block, XFR_BAD_SUBDISK   (skipped at launch)
```

The last LAUNCHED element is rqe[1]; rqe[2] is a TRAILING skipped
element. With md (malloc) backing, biodone() runs inline inside
dev_dstrategy(), so rqe[1]'s completion runs complete_rqe() ->
complete_raid5_write() (XOR + phase-2 data write + parity write), whose
own inline completions drive rq->active to 0 and **freerq() the entire
request while launch_requests() is still inside its launch loop**
(`sys/dev/raid/vinum/vinumrequest.c:395-440`). The loop then reads
`rqg->rqe[2].flags` and `rqg->next` (`:408-409`) from the freed group;
kmalloc's freelist pointer overwrites rqg->next and the loop dereferences
garbage:

```
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
Stopped at launch_requests+0xc2: movq (%rax),%rax
```

Reproduced 2/2 baseline runs (once via the plain designed-degraded write
with `rv.p0.s2` down, once via DF-4714's two-reborn trigger — identical
signature). This is the "at least one further lifetime defect in the
relaunch path" that DF-4482's verification predicted after its two
waitlist fixes failed to stop that panic: **this arm needs no revive and
no waitlist at all** — just a degraded RAID-5 write whose trailing rqe
is a skipped BAD_SUBDISK, on any drive completing synchronously in
strategy (md; also plausible with other stacking).

## Trigger

Same array as DF-4714. `sh ../DF-4714/setup_vinum.sh`;
`vinum setstate -f down rv.p0.s2; ./trigger` (single 32KB write at
volume sectors [128,192)) → panic within milliseconds.

## Fix validation

`fix.diff` snapshots `rqg->next` before any firing and bounds the launch
loop to the last non-BAD rqe (precomputed), so no group memory is read
after an inline completion can free it. Applied + kernel rebuilt:
**write succeeds (correct degraded semantics), readback matches, no
panic** (`run.patched.log` step 3); DF-4714's panicking trigger now gets
a clean EIO instead.