DF-5062 — vinum volume minor aliasing (volno >= 256 wraps into VOL[0])

What

made_vol() (sys/dev/raid/vinum/vinumconfig.c:763) creates each /dev/vinum/vol/<name> node with VINUMDEV(vol->volno, 0, 0, VINUM_VOLUME_TYPE) and never checks that the volume number fits in the VINUM_VOL_WIDTH = 8 low bits of the minor (sys/dev/raid/vinum/vinumvar.h:83-86,113-116). Nothing else bounds the volume count: get_empty_volume() (vinumconfig.c:875-899) grows VOL[] indefinitely. Creating the 257th volume gives volume #256 the minor 0x100, which Volno() (sys/dev/raid/vinum/vinumutil.c:241) decodes as volno 0 — every open/read/write/ioctl/DIOCGPART on /dev/vinum/vol/v256 is served by VOL[0], a different volume. Deterministic cross-volume data corruption and wrong-object sizing from ordinary root vinum configuration.

Kernel minor() returns the raw si_uminor (sys/kern/kern_conf.c:70-75), so the wrap reaches vinum even though makeudev() (kern_conf.c:154-160) flags minor 0x100 as NOUDEV for the stat path — that is why ls -l /dev/vinum/vol/v256 displays the bogus rdev 255, 0xffff00ff while open()/read()/write() still execute against VOL[0].

How to reproduce (root on the DragonFly guest)

# push label.bin (from findings/poc/DF-4592) + df5062_volalias.sh
kldload vinum
sh /tmp/df5062_volalias.sh        # creates vn0 drive, v0 (4 MB sd), v1..v256
sh /tmp/alias2.sh                 # explicit data-aliasing check (od output)

Expected on a vulnerable kernel:

1. /dev/vinum/vol/v256 exists with the bogus rdev 255, 0xffff00ff (v0/v255 show 32, 0x00000000 / 32, 0x000000ff).
2. diskinfo /dev/vinum/vol/v256 reports v0's size (0x400000 = 4 MB), though v256 has zero plexes and size 0.
3. Writing BBBB-v256-ALIAS through /dev/vinum/vol/v256 and reading back through /dev/vinum/vol/v0 returns BBBB — writes through v256 land in v0's storage.

All three reproduced (run.log, run.2.log).

Fix validation

fix.diff (against sys/, applied in the guest's /usr/src, vinum.ko rebuilt standalone, installed, rebooted):

• kernel logs vinum: volume v256: volume number 256 does not fit in the 8-bit device minor; no device node created;
• /dev/vinum/vol/v256 no longer exists (write → ENOENT);
• positive control intact: v0 still reads/writes its own data (fix_run.log, fix_run2.log).

Notes

• Root-gated (vinum configuration requires the root-only superdevice, vinum.c:457-468) — same threat model as the rest of the vinum family.
• The same wrap turns volume #512's node into minor 0x200 → VOL[0] again, #768 → 0x300, etc.; every multiple of 256 aliases onto VOL[0].
• fix.diff also carries the DF-5063 hardening hunk for vinumutil.c (bounds-checked composite-minor decode); both were validated together.

DF-5062 — VERDICT

Status: REPRODUCED (deterministic, twice, plus fix-validated). Impact: deterministic cross-volume data corruption + wrong-object sizing. Root-gated (vinum config path), hence Medium, not High.

Root cause (line-accurate)

• sys/dev/raid/vinum/vinumvar.h:83-86 — VINUM_VOL_SHIFT=0, VINUM_VOL_WIDTH=8: a volume device minor holds the volume number in 8 bits.
• sys/dev/raid/vinum/vinumvar.h:113-116 — VINUMDEV(v,p,s,t) = v<<0 | p<<16 | s<<20 | t<<28; nothing masks v.
• sys/dev/raid/vinum/vinumconfig.c:759-774 — made_vol() does make_dev(&vinum_ops, VINUMDEV(vol->volno,0,0,VINUM_VOLUME_TYPE), ...) with no range check on vol->volno; get_empty_volume() (vinumconfig.c:875-899) expands VOL[] without limit.
• sys/dev/raid/vinum/vinumutil.c:238-242 — Volno(dev) = (minor(dev) & MASK(8)) >> 0 → minor 0x100 decodes as volno 0.
• sys/kern/kern_conf.c:70-75 — kernel minor(cdev_t) returns the raw si_uminor (256), so vinum really is entered with 0x100; kern_conf.c:154-160 makeudev() only rejects it for the stat path (ls -l shows 255, 0xffff00ff — the NOUDEV pattern), which is cosmetic.

Reproduction evidence

run.log (stock module, fresh vm.sh reset with-src boot): * 257 volumes created (vinum l header: 257 volumes:). * ls -l /dev/vinum/vol/v256 → crw- 255, 0xffff00ff (v0: 32, 0x00000000). * diskinfo /dev/vinum/vol/v256 → size=0x000000400000 4.00 MB — exactly v0's size, while v256 has Plexes: 0 Size: 0 B. * run.2.log (explicit od dump): write AAAA-v0-mark via v0 → read via v0 = AAAA; write BBBB-v256-ALIAS via v256 → read via v0 = BBBB. Writes through v256 land in v0's storage.

Impact ceiling

Any vinum deployment with ≥257 configured volumes (volume numbers are handed out sequentially and never reused until removal): all I/O to the aliased node silently reads/writes a different volume — filesystem corruption, swap-on-wrong-volume (DIOCGPART serves v0's geometry), and the bogus st_rdev shown by stat. Attack path is the ordinary root vinum configuration interface (vinum create -f), the same privilege class as every other vinum finding in this audit (superdev open is SYSCAP_RESTRICTEDROOT, vinum.c:457-468).

Fix validation (done in this run)

fix.diff applied to the guest's /usr/src, vinum.ko rebuilt standalone (make rc=0, fix_build.log), installed to /boot/kernel, rebooted, PoC re-run (fix_run.log, fix_run2.log): * kernel logs vinum: volume v256: volume number 256 does not fit in the 8-bit device minor; no device node created; * /dev/vinum/vol/v256 absent; write attempt → ENOENT (aliasing gone); * positive control: v0 data I/O intact (PATCHED-OK/AAAA readbacks).

Not pursued

The minor-wrap also corrupts plex/sd sub-minor fields for volno ≥ 65536 (volno bits spill into bits 16+), but 65k+ volumes is not a realistic configuration; the 8-bit wrap is the practical case.

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.