# DF-4596 — VERDICT

**Status: untested** (code-certain; no guest run — the leak is 256 B per
re-init cycle into M_DEVBUF and not observably attributable on the guest
without allocation-site accounting).

## Analysis

* `sys/dev/raid/vinum/vinumio.c:144-145` — unconditional
  `drive->freelist = Malloc(16 * sizeof(struct drive_freelist))`.
* Lifetime facts verified in source:
  * `close_locked_drive()` (vinumio.c:218-230) drops only the vnode;
  * `free_drive()` (vinumconfig.c:572-588) is the only freer of `freelist`
    and it also `bzero`s the drive — it runs on *removal*, not on
    state-down transitions;
  * therefore a drive that goes `up → down` while staying allocated
    (`set_drive_state(…, drive_down, …)` from e.g. `daemon_save_config()`
    write errors or `vinum setstate`) keeps `freelist != NULL`, and the next
    `read_drive_label()` → `init_drive()` → `set_drive_parms()` for the same
    device name (re-scan, `vinum read`, boot scan) overwrites the pointer.

Classification: slow kernel heap leak, administrator/boot-triggered — Low.

## 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.

(No fix.diff for this item: documented recommendation only - see Fix above.)