DF-5063 — vinum Plexno()/Sdno() composite-minor decode walks tables unvalidated (latent OOB)

What

Plexno() and Sdno() (sys/dev/raid/vinum/vinumutil.c:250-297) decode the composite VINUM_PLEX_TYPE / VINUM_SD_TYPE minor layouts with no bounds checks, and propagate the -1 "empty slot" sentinel that get_empty_volume() stores in vol->plex[] (vinumconfig.c:896-897):

case VINUM_PLEX_TYPE:              /* vinumutil.c:261 */
case VINUM_SD_TYPE:
    return VOL[Volno(dev)].plex[(minor(dev) >> 16) & MASK(3)];   /* may be -1 */
...
case VINUM_SD_TYPE:                /* vinumutil.c:289 */
    return PLEX[Plexno(dev)].sdnos[(minor(dev) >> 20) & MASK(8)]; /* PLEX[-1]! */

A VINUM_SD_TYPE minor whose plex ordinal addresses an empty slot makes Plexno() return −1, and Sdno() then reads PLEX[-1].sdnos[ordinal] — a heap out-of-bounds read up to ~1 KB before the plex[] array whose value is then used as an index into SD[]. Callers only check >= (vinum.c:430-440), which −1 survives as a signed value.

Reachability — why this is only Info

The kernel never creates composite-minor device nodes: the only make_dev sites are VINUM_SD(sdno) (rawsd), VINUM_PLEX(plexno) (rawplex) and volume nodes (vinumconfig.c:740,763,780). The sole way to feed a composite minor to vinum is a hand-made node (mknod).

On this DragonFly (6.5-DEVELOPMENT guest) that route dies before vinum. Reading a hand-mknod'ed character node — even with a valid vinum rawplex minor (0x50000000) — panics the kernel in the generic device-resolution layer: Fatal trap 12 ... Stopped at dev_dflags: movq 0xa8(%rdi),%rax with rdi = 0 (NULL cdev), current process dd (panic.txt; reproduced twice). UFS-mknod'ed VCHR vnodes never get a resolved v_rdev (addaliasu() only stores v_umajor/v_uminor, sys/kern/vfs_subr.c:1246-1252) and some path dereferences it unchecked. So Plexno()/Sdno()'s composite branches are dead code today — reported as hardening (defense-in-depth, and the identical PLEX[-1] sink is already exploitable through the config path per DF-1399).

What was run (root on the guest)

• df5063_setup.sh — vn0 drive, v0 (plex p0, sds s0/s1), up.
• df5063_sdcomp.sh — original mknod(1) sweep: the guest has no mknod binary (run.log).
• df5063_mknod.c — mknod(2)+open(2) probe tool (built clean).
• Step-by-step probe: reading /tmp/px0 (mknod'ed valid rawplex minor) wedged the guest → Fatal trap 12 in dev_dflags (panic.txt). Composite minors never reached vinum.

Fix (validated as part of DF-5062's rebuild)

fix.diff (same file as DF-5062's pack) adds explicit bounds checks to both composite branches of Plexno()/Sdno() (volno against volumes_allocated, plexno against plexes_allocated, -1 never used to index). Patched-module regression (fix_run.log, fix_run2.log): raw sd / rawplex / volume read-write all intact.

Cross-file observation for the orchestrator

The mknod'ed-node read NULL-deref (dev_dflags(NULL)) is a separate, non-vinum bug in the UFS→spec/devfs chain, root-gated local DoS, reproducible on demand (see panic.txt + run.log/run.2.log). Suggest a spawn on sys/vfs/devfs/devfs_vnops.c / sys/kern/vfs_subr.c.

DF-5063 — VERDICT

Status: NOT REPRODUCED (unreachable on this system; Info hardening). The code defect is certain by inspection; the composite-minor paths that reach it are dead code on DragonFly, and the only way to synthesize such a minor (a hand-made device node) panics the kernel upstream of vinum.

The defect (certain, static)

• sys/dev/raid/vinum/vinumutil.c:261 — Plexno() VINUM_PLEX_TYPE/SD_TYPE case: VOL[Volno(dev)].plex[ordinal] with no check of Volno(dev) against volumes_allocated and no handling of the -1 stored in empty vol->plex[] slots (vinumconfig.c:896-897).
• sys/dev/raid/vinum/vinumutil.c:289 — Sdno() VINUM_SD_TYPE case: PLEX[Plexno(dev)].sdnos[ordinal]; when Plexno() returns −1 this is a heap OOB read at PLEX_base − sizeof(struct plex) + offsetof(sdnos) + 4*ordinal (≈ −112 … +908 bytes around the allocation), whose garbage value is then used to index SD[].
• Callers check only >=: vinum.c:430-431 (Plexno(dev) >= plexes_allocated is false for −1, signed) and vinum.c:438 (the OOB-read value must only be < subdisks_allocated and pass the SD state check).
• Same terminal sink as DF-1399 (config kw_prefer path), different entry.

Why unreachable at runtime here

1. No kernel make_dev creates composite minors — only VINUM_SD(sdno)/VINUM_PLEX(plexno) (raw) and volume nodes exist (vinumconfig.c:740,763,780; verified on the guest: /dev/vinum/sd/s0 = 0x60000000, /dev/vinum/plex/p0 = 0x50000000).
2. A hand-made node cannot reach vinumopen: reading an mknod'ed char node (VALID rawplex minor 0x50000000) panics in dev_dflags(NULL) before any vinum code runs — twice reproduced (panic.txt; step-1 probe). Root cause of that panic is in the generic UFS→spec/devfs resolution (no resolver populates v_rdev for mknod'ed VCHR vnodes on DF; addaliasu only stores v_umajor/v_uminor — sys/kern/vfs_subr.c:1246). → separate cross-file bug, root-gated DoS, not vinum's.

Runs

• run.log — full sweep with mknod(1): guest has no mknod binary; setup OK.
• run.2.log — mknod(2) tool first used; argc bug in the tool (fixed).
• run.3.log — corrected probe: hung → panic (dev_dflags NULL, proc dd).
• Step-by-step after reset: FIRST hand-made node read (valid minor!) → panic again → attribution: generic layer, not composite minors.
• fix_run.log / fix_run2.log — patched-module regression: raw sd/plex/vol I/O all correct after the Plexno/Sdno bounds checks (fix.diff shared with DF-5062, rebuilt vinum.ko).

Disposition

File as Info (hardening): the unvalidated walks should be bounded so the latent PLEX[-1] cannot be resurrected by any future composite-node creation. No runtime impact demonstrated (and demonstrably blocked upstream today). Recommended fix included and compile+regression validated.

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.