DF-5108 — VERDICT

Status: not_reproduced (race-gated heap OOB write; code path certain, race window not reached within guest budget). Impact class: memcorrupt.

Defect (static, vinumlock.c)

The rangelock allocator can commit pos = one-past-the-end of the 256-entry lock table:

1. :139 while (plex->usedlocks == PLEX_LOCKS) — equality only. Any usedlocks > PLEX_LOCKS (produced by the bug itself, or by the unprotected usedlocks++/-- RMW pair across CPUs — :190 vs :219 in interrupt-context unlockrange) permanently defeats the wait AND the full-table wakeup at :220 (waiters then sleep in tsleep("vlock") forever, no PCATCH).
2. The conflict path :155-171: a requester that finds its stripe held by another request tsleeps on that lock entry. tsleep drops the MP token (vinum is non-MPSAFE — kern_device.c:121 wraps every entry point with get_mplock), so while it sleeps, other CPUs' requests consume free slots. unlockrange frees the conflicting entry and wakes it, but a third request can retake that entry before the sleeper is scheduled.
3. The sleeper then rescans (:168-170, no fullness recheck) with all 256 slots in use: the scan runs to lock == &plex->lock[PLEX_LOCKS], pos stays NULL, and :181-182 sets pos = lock — one past the end.
4. :188-190 writes pos->stripe (attacker-influenced 64-bit disk offset) and pos->bp (kernel pointer) 16 bytes past the kmalloc(PLEX_LOCKS * sizeof(struct rangelock)) = 4096-byte object (vinumconfig.c:1467), and increments usedlocks past 256 — feeding (1): every subsequent lockrange on this plex repeats the OOB write.

Reachability: rangelocks are acquired only for RAID-5 plex request groups (vinumraid5.c:592 rqg->lockbase = m.stripebase → vinumrequest.c:396-397 inside launch_requests' crit section — whose own comment admits the bottom half completes concurrently). Any local user generating concurrent I/O on a vinum-backed filesystem reaches lockrange; the race needs the table exactly full at a wake boundary.

What was attempted (guest, 6 vCPU)

• Built a live RAID-5 volume (3 × 100 MB vn-backed drives, 32 KB stripes, forced up) and hammered /dev/vinum/vol/rv with the included lockrange_race (pwrite from N threads at random offsets from a P-stripe pool to force same-stripe conflicts + near-full table).
• Three completed runs (see run.log): 400×32K×300 stripes × 300 s; 800×32K×270 × 300 s; 300×128K×258 × 300 s — ≈11 M write ops, 0 errors, no panic, no "vlock" wedge, dmesg clean.
• Why it did not fire: aggregate throughput × service time implies ~80-160 concurrently-held slots; the table never reached 255+1 at a wake boundary. The vn-on-virtio backing completes too quickly to accumulate ≥256 in-flight request groups; the MP token serializes submissions further. A production array with real disk latency and deep queues (or a slower backing device) reaches fullness routinely — that is exactly the regime the striped-lock design was written for.
• Instrumentation attempt (ulmon.c) to read plex->usedlocks via VINUM_PLEXCONFIG failed on the ioctl size-encoding probe; not pursued further within budget.

Conclusion

Not reproduced in budget — the interleaving is real (every ingredient is individually present: token-dropping sleeps, interrupt-context decrements, equality checks, the unconditional pos = lock) but requires ≥256 in-flight RAID-5 groups at a wake boundary, which this guest's I/O stack does not sustain. The finding stands as a race-gated heap OOB write with permanent repeat-after-first-hit semantics (usedlocks overrun). Severity Medium, confidence likely.

Fix

fix.diff (same file as DF-5109's fix): ==→>= both fullness checks, post-tsleep goto restart recheck, defensive end-of-table guard before commit, crit_enter/crit_exit around unlockrange's update. Validated to build and boot (see DF-5109 fix validation); no behavioral regression in the hammer runs' I/O path (runs completed identically on the patched kernel during validation).

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.