DF-5109 — VERDICT

Status: reproduced (impact: panic — kernel double/invalid free, BADFREE2) Confidence: certain that the race kills the kernel (2/2); likely on the exact recursion arm (see attribution).

What was run

Guest: DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026 X86_64_GENERIC, 6 vCPU, vinum.ko + /dev/vinum/control (0600, root).

Setup (setup.sh): 4 vn-backed drives with vinum-fstype partitions (disklabel64 fstype 14) and on-disk vinum labels; raid5 volume rv (x0/x1/x2, 3 sds, up) for realism; drive d0 on /dev/vn3s1a.

PoC (lockdrive_recursion.c, root): the process issues VINUM_DAEMON — vinumioctl.c:296 runs vinum_daemon() in the caller's process, so the daemon's close_drive() calls share the issuer's pid. Then: * 6 "downer" threads: VINUM_SETSTATE(drive, down, force) + VINUM_REMOVE(index, force) in a tight loop on the drive slots; * 6 "cycler" threads: rewrite the on-disk label (pwrite at 4096), VINUM_CREATE "drive d0 device /dev/vn3s1a", VINUM_SETSTATE up, every 20 ms.

Observations

• Run 1 (90 s × 8 racers): panic: BADFREE2 after ~35 s; trace fragments _kfree+0x593 / mapped_ioctl+0x492 / syscall2+0x11e; guest wedged in DDB (db>), ssh dead, vm.sh status ⇒ down. (serial console)
• Run 2 (fresh vm.sh reset with-src, clean vinum config, dmesg cleared, 60 s × 6 racers): panic: BADFREE2 after ~3-6 s with the full intact trace: panic: BADFREE2 cpuid = 2 _kfree() at _kfree+0x593 _kfree() at _kfree+0x593 mapped_ioctl() at mapped_ioctl+0x492 syscall2() at syscall2+0x11e Guest wedged in DDB again → reset required.
• BADFREE2 is kfree()'s allocation-integrity check: the pointer passed to Free() (vinum's kmalloc wrapper) inside the vinum ioctl path was not a live allocation — i.e. a double free or stale free of a drive-teardown allocation (drive->freelist via free_drive/ set_drive_parms, or the remove_drive label buffer).

Why this is the lockdrive section violation

• The freed objects belong to the drive teardown path that LOCKDRIVE()/unlockdrive() (vinumlock.c) exist to serialize (close_drive vinumio.c:205, free_drive vinumconfig.c:576, daemon_save_config vinumio.c:594).
• Every one of those sections sleeps internally (vn_close(), write_drive()) — releasing the MP token — while VF_LOCKED stays set.
• lockdrive()'s pid check (vinumlock.c:59-75) admits any same-process thread during that window without waiting; with the daemon running in the ioctl issuer's process (VINUM_DAEMON semantics) plus our own threads, both close_locked_drive() executions and both Free(drive->freelist) paths run concurrently:
• double vn_close(drive->vp) (vp still set while the first vn_close sleeps — cleared only after it returns), → vnode refcount underflow;
• both threads pass if (drive->freelist) before either's side effect lands → double Free, or a stale Free against a freelist freshly Malloc'd by the re-creating cycler → BADFREE2 exactly as captured.

Attribution caveat (recorded honestly)

The PoC necessarily races several ioctls at once (that is the only way to keep drives cycling through the section), and the unconditional "vinum lockdrive: already locking" warning (vinumlock.c:70-73) was not captured on the flooded serial console before either panic. The pid-identity defect is proven statically; the captured double-free is in precisely the section whose exclusivity the defect destroys. The adjacent unlocked-ioctl race family (DF-4478) supplies the concurrency but does not by itself turn two Free() calls of the same pointer into code — the second entry into the section requires lockdrive() to admit it.

Fix validation

fix.diff applied to the guest's /usr/src copy (never to the repo sys/): pid early-return removed (all callers wait), crit sections around the flag RMWs, and the == fullness checks corrected (lockrange half). Kernel rebuilt (X86_64_GENERIC) and the identical PoC re-run: see verdict.json fix_* fields for the outcome (fix_baseline_reproduced=1; patched result in fix_patched_reproduced / fix_verdict / fix_evidence).

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.