DF-5010 — vkernel vdisk (vkd) lacks driver-level I/O bounds checking

File: sys/dev/virtual/vkernel/disk/vdisk.c Class: CWE-787/CWE-125 (latent), defense-in-depth Severity: Info (hardening) — NOT exploitable on any currently reachable path Verification: built a full vkernel64 inside the QEMU DF guest, booted it with a COW disk (-R), and fired 512-aligned raw OOB reads/writes at /dev/vkd1 and /dev/vkd2 as guest root (PID 1). All were rejected by the generic slice layer (dscheck()) before reaching vkd_doio(); the vkernel host process survived every attempt and the backing files never grew.

What the trigger does

vkd_bounds.c runs as PID 1 inside the vkernel (via -e init_path=/poc):

• mounts devfs,
• pwrite/pread 512-byte blocks at: offset 0 (in bounds), exact EOF, size+512, and 1 TB on both the plain (-r) and COW (-R) disks.

Expected (and observed) on a stock kernel:

• in-bounds I/O succeeds;
• OOB I/O returns -1/EINVAL (silent dscheck bounds rejection, sys/kern/subr_diskslice.c:253→294);
• the vkernel process survives; plain.img never grows;
• when PID 1 exits the vkernel panics with panic: Going nowhere without my init! — expected and harmless.

vkd_oob.c is the earlier unaligned variant (4-byte writes); it demonstrates the alignment rejection (dscheck(vkdN): b_bcount 4 is not on a sector boundary, see run.log).

How to reproduce (inside the DF QEMU guest, as root)

# 1) build the vkernel (see build.sh; note: vkernel64 link is currently
#    broken in HEAD — kern_mib.c needs __build_id_start/end which the
#    vkernel conf/Makefile SYSTEM_LD override never defines; work around
#    with -Wl,--defsym, see build.sh)
# 2) build a UFS root image containing the static PoC at /poc (build.sh)
# 3) run:
sysctl vm.vkernel_enable=1
cd /root/vk
timeout 90 ./vkernel64 -m 256M -r root.img -r plain.img -R cow.img \
    -e init_path=/poc < /dev/null > run3.log 2>&1
# 4) observe: "vkd2: COW disk", "init died (signal 0, exit 0)", no kernel
#    fault, plain.img still 16777216 bytes.

Bottom line

• vkd_doio() (vdisk.c:303-347) performs bcopy(sc->map_buf + bio_offset, …) (COW mode) and pread/pwrite() (regular mode) with no validation of bio_offset/b_bcount against sc->size.
• Every currently reachable path into vkdstrategy() is bounds-checked by dscheck() first — including the whole-disk nodes, because disk_create() exposes only the disk-core (disk1_ops/disk2_ops) covering devices in devfs (sys/kern/subr_disk.c:691-712).
• The in-tree precedent for bypassing dscheck exists: whole-disk raw-access partitions ≥128 (sys/kern/subr_diskslice.c:171-175, created e.g. by fd.c:1036-1054) are passed to the driver unbounded. If vkd ever grows such nodes (or any bio source skips dscheck), COW mode turns into an arbitrary-offset OOB read/write inside the vkernel host process.
• The fix (see fix.diff) adds the driver-level check and also clamps the b_resid computation for pread/pwrite == -1 (error) returns, which today computes resid = bcount + 1; harmless on x86-64 because std_copyout's address-wrap guard (sys/platform/pc64/x86_64/support.s:247-249) turns the resulting (size_t)-1 copyout length into an immediate EFAULT.

DF-5010 VERDICT — vdisk missing bounds check: shielded by dscheck(); not exploitable today; hardening fix validated

Reproduced?

The OOB itself: NO — and that is the verified security conclusion. The driver-level missing check is real, but every path a guest can drive into vkdstrategy() is bounded by the generic slice layer before vkd_doio() sees the bio. Verified three ways:

1. Code trace (the shield): * Every devfs-visible vkd node is a disk-core covering device (disk1_ops/disk2_ops, sys/kern/subr_disk.c:716-745), whose d_strategy is diskstrategy → dscheck() (sys/kern/subr_disk.c:1240-1246, sys/kern/subr_diskslice.c:91). * dscheck() rejects negative offsets (subr_diskslice.c:110), enforces sector alignment (:131-143), and bounds secno + nsec against the slice/disk end with truncate/EOF/EINVAL semantics (:253-277). * The only dscheck bypass in the system — whole-disk raw-access partitions ≥ 128, "fed directly through to the device with no further interpretation" (subr_diskslice.c:171-175) — requires dev_t minors that vdisk never creates (only fd.c:1036-1054 creates such nodes). * The dump path is separately bounded (diskdump() → disk_dumpcheck() + explicit range check, sys/kern/subr_disk.c).
2. Empirical, run 1 (run.log, unaligned 4-byte I/O): kernel printed dscheck(vkd1): b_bcount 4 is not on a sector boundary and dscheck(vkd2): … for every attempt — proving dscheck is interposed on the raw whole-disk nodes the PoC opened.
3. Empirical, runs 2-3 (run.2.log, run.3.log, 512-aligned): all six OOB attempts (write @1 TB, write @size+512, read @1 TB, on both plain and COW disks) completed without any kernel-mode fault — a wild COW bcopy would have killed the vkernel host process before "init died" appeared — the PoC ran to completion (init exit 0), and plain.img never grew (16777216 bytes before and after; md5 unchanged): the 1 TB pwrite never reached the backing file. The aligned bounds-rejection path in dscheck (:259 → :294) is silent, which is why no diagnostic appears.

The latent hazard (why this is still filed)

• COW mode (-R, flags & 1): vkd_doio() does bcopy(sc->map_buf + bio->bio_offset, bp->b_data, bp->b_bcount) (vdisk.c:310-314, :322-326) — sc->map_buf is a host-process mmap of length sc->size (vdisk.c:133-141). An unbounded bio is an arbitrary-offset OOB read/write inside the vkernel host process (guest-root → host-process memory corruption; VM-sandbox break).
• Regular mode: pwrite() at an unbounded offset silently extends the host backing file (sparse growth to attacker-chosen size — host disk-fill).
• DragonFly's own fd.c demonstrates that dscheck-bypassing raw partitions are a supported driver feature; the day vkd grows them, the missing check becomes exploitable. FreeBSD's md(4) checks bounds in-driver for exactly this reason.

Secondary finding (killed): b_resid underflow

bp->b_resid = bp->b_bcount - n (vdisk.c:346) with n = -1 (pread/pwrite error, e.g. NFS-backed disk going down, ENOSPC) computes resid = bcount + 1. physio() then computes iolen = b_bcount - b_resid = (size_t)-1 and calls copyout(bp->b_data, ubase, iolen) (sys/kern/kern_physio.c:104). On x86-64 std_copyout pre-checks address wrap (udaddr + len carry → immediate EFAULT, sys/platform/pc64/x86_64/support.s:247-249), so no bytes are copied — the disclosure is dead; only uio accounting wraps (loop exits with the I/O error). Clamped anyway in fix.diff for correctness.

Fix validation

• fix.diff applied to the guest's /usr/src (checksum-identical to the audit tree), vkernel rebuilt (build-fix.log, 21:35 kernel.stripped), rerun (run.4-fixed.log): identical clean behaviour — COW disk armed, PoC completed (init exit 0), vkernel survived, plain.img md5 unchanged. No regression; the driver-level rejection is now armed as defense-in-depth.
• Baseline vs patched: baseline (stock) did not reproduce the OOB (shielded); patched also does not reproduce; in-bounds I/O unaffected.

Environment / build notes

• Guest: DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC (see env.txt).
• vkernel64 is currently un-buildable in HEAD: conf/Makefile's SYSTEM_LD override drops the -Wl,-T,ldscript.x86_64 that defines __build_id_start/__build_id_end, which kern/kern_mib.c:102-103 now references → link failure (see build.log). Worked around guest-side with -Wl,--defsym (not part of the fix — upstream should either re-add the ldscript to SYSTEM_LD or guard kern_mib.c).
• vkernel assets: sysctl vm.vkernel_enable=1, /var/vkernel must exist.

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.