DF-2902 — unvalidated d_media_blksize in mbrinit → oversized kernel read into 128 KB pbuf

What

mbrinit() (sys/kern/subr_diskmbr.c:127-132) issues a synchronous read of exactly info->d_media_blksize bytes into a getpbuf_mem() pbuf whose buffer is only MAXPHYS (128 KB on x86_64) bytes:

bp = getpbuf_mem(NULL);
KKASSERT((int)info->d_media_blksize <= bp->b_bufsize);   /* :128 — broken guard */
bp->b_bio1.bio_offset = (off_t)mbr_offset * info->d_media_blksize;
bp->b_bcount = info->d_media_blksize;                    /* :132 — sink */

The guard is broken twice: 1. KKASSERT is compiled out entirely on non-INVARIANTS (production) kernels. 2. The (int) cast makes any block size ≥ 2^31 (e.g. 0x80000000 → INT_MIN) pass the assertion even on INVARIANTS kernels.

d_media_blksize is attacker-controllable by any malicious storage device: scsi_da.c:dasetgeom() copies the READ CAPACITY length field verbatim into softc->params.secsize (sys/bus/cam/scsi/scsi_da.c:2289) with no validation, so a USB mass-storage gadget answering READ CAPACITY with length=0x80000000 delivers it straight into mbrinit at plug-in (devd/CAM auto-probe runs as root). The same value flows to mbr_extended() (subr_diskmbr.c:435-439).

Observed (stock INVARIANTS guest, DragonFly 6.5-DEVELOPMENT)

• blksize = 0x40000 (256 KB): panic: assertion "(int)info->d_media_blksize <= bp->b_bufsize" failed in mbrinit at subr_diskmbr.c:128 (see panic_runA.txt).
• blksize = 0x80000000 (2 GiB): assertion BYPASSED via the cast; the read is issued with b_bcount = 0x80000000 into the 128 KB pbuf; the transfer memmove runs off the end of the mapped buffer → kernel-mode page fault: trap 0xc, rip = memmove+0x10a (see panic_runB.txt). The overflow content is the attacker's data (the bytes the device/backing file supplies).

Threat

Crafted MBR media is NOT required — only a device that lies about its block size (USB mass-storage, malicious virtual disk, misbehaving HBA). On the real CAM path the same b_bcount becomes the SCSI dxfer_len (scsi_da.c:1492-1506, scsi_minphys is #if 0'd), i.e. a device-directed DMA of up to 2 GiB into a 128 KB kernel buffer — attacker-chosen content and length: code-execution-grade primitive. Reach: plug-in auto-probe (no privilege needed by the attacker beyond physical access).

Reproduce (guest, root)

dd if=/dev/zero of=/root/med.img bs=1m count=256
vnconfig -c -S 512 vn0 /root/med.img        # clean zero media
cd /root/mbrprobe && make                   # KLD harness
kenv mbrprobe.blksize=262144   && kldload ./a/mbrprobe_a.ko   # panic at :128
# reset, reattach vn, then:
kenv mbrprobe.blksize=2147483648 && kldload ./b/mbrprobe_b.ko # OOB memmove panic

Success criterion: panics above on the stock kernel; after fix.diff both runs print mbrprobe: mbrinit returned 5 (EIO) and the guest stays up.

DF-2902 VERDICT

Status: reproduced (both legs) — impact: kernel memory corruption (proven OOB write w/ attacker-controlled content and length; demonstrated as panic), gated on a malicious-storage-device / root trigger.

Chain (all lines verified in-guest)

1. Attacker device answers SCSI READ CAPACITY(10/16) with length = chosen value. scsi_da.c:1831/1850 block_size = scsi_4btoul(...); dasetgeom() scsi_da.c:2289 dp->secsize = block_len; — no validation anywhere.
2. scsi_da.c:1863 info.d_media_blksize = softc->params.secsize → disk_setdiskinfo() (subr_disk.c:853) → _setdiskinfo computes d_media_size = blocks*blksize (nonzero, so mbrinit's media-size guard passes) → DISK_DISK_PROBE.
3. disk_msg_core (holding ds_token, subr_disk.c:512) → disk_probe (subr_disk.c:371) → mbrinit().
4. subr_diskmbr.c:118 blksize & DEV_BMASK — passes for any 512-multiple. subr_diskmbr.c:128 KKASSERT((int)blksize <= bp->b_bufsize): * 0x20000 < blksize < 0x80000000 (512-multiple) → fires on INVARIANTS kernels (panic reproduced, panic_runA.txt: blksize=0x40000); * blksize ≥ 0x80000000 → (int) cast makes it negative → assertion passes on every kernel.
5. subr_diskmbr.c:132 bp->b_bcount = blksize on a pbuf whose b_data is a MAXPHYS (128 KB, sys/cpu/x86_64/include/param.h:122) KVA window (vm_pager.c:263/391).
6. The read walks diskstrategy→dscheck (all boundary checks pass: the arithmetic is self-consistent in wrap-around int space — verified subr_diskslice.c:124-282) → raw dev strategy. On CAM: scsi_da.c:1492-1506 scsi_read_write(..., bp->b_data, bp->b_bcount) with scsi_minphys #if 0'd (scsi_da.c:706-711) → dxfer_len = up to 2 GiB DMA into the 128 KB pbuf. In the harness (vn transport) the equivalent is the uiomove copy (vn.c:323-333): kernel-mode page fault in memmove reproduced (panic_runB.txt: trap 000000000000000c, rip = memmove+0x10a).

Why not uid0

The entry vector is device-attach-time probe: it requires a malicious storage device (hardware; no USB gadget emulation is available on this QEMU guest to fake READ CAPACITY block length) or root (vnconfig/KLD). There is no unprivileged-local entry to this path (opening disk devices requires SYSCAP_RESTRICTEDROOT, subr_disk.c:1072). The corruption primitive itself (attacker bytes, attacker length, deterministic forward overflow from a pager_map pbuf slot) is fully demonstrated; weaponizing to uid0 needs the hardware vector and target-grooming work that the guest cannot host. Recorded as memcorrupt/High with panic-level demonstrated impact.

Fix validation (this run)

• fix.diff adds if (info->d_media_blksize < DEV_BSIZE || info->d_media_blksize > MAXPHYS) return (EIO); at subr_diskmbr.c:121 (plus the DF-2903 hunk), built with make nativekernel in-guest and booted.
• Baseline (stock kernel): panic at :128 (blksize 0x40000); OOB memmove page-fault panic (blksize 0x80000000). Patched kernel: both runs print mbrprobe: mbrinit returned 5 (EIO) and the guest stays up — bad behavior GONE. See run_fix_*.log, fix_build.log.