DF-2876 — BLK_READ at/after EOF returns stale shared pbuf memory to the

dmsg peer (cross-process / cross-device kernel-mediated info leak)

What this pack contains

• dfpeer.c — dmsg wire peer (see DF-2875 pack).
• run_f3.sh — sets up a vn(4) disk containing 16MB of "secret" pattern, seeds the shared pbuf-mem pool by physio (dd if=/dev/vn0 of=/dev/null), then issues BLK_READ at EOF through the dmsg channel.
• leak_sample.txt — the three leak runs + md5s; run 1 returned a full 64KB block identical to the secret image (md5 7081aa33...), run 2 returned the boot disk's MBR boot code (fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c...) through a different disk's channel, run 3 returned stale dmsg write aux (0xAA fill).
• fix.diff — diskiodone READ: on B_ERROR attach no data; on short reads attach only completed bytes.

Root cause

diskiodone (sys/kern/subr_diskiocom.c:594-597) sets data = bp->b_data; bytes = bp->b_bcount for BUF_CMD_READ before looking at B_ERROR / b_resid, and unconditionally attaches bytes of buffer content to the reply (:651-655). A read that transfers nothing (EOF: vn's VOP_READ returns success with untouched uio_resid → b_resid = b_bcount, no B_ERROR) therefore ships the previous contents of the shared getpbuf_mem KVA arena to the peer. That arena is shared with kern_physio (every raw device I/O of every process), disklabel/GPT/MBR probes, and other dmsg I/Os (sys/vm/vm_pager.c:505, sys/kern/kern_physio.c:43).

Build & run (root on the DF guest)

cc -O -Wall -o /tmp/dfpeer dfpeer.c
sh run_f3.sh

Expected output (stock kernel)

eofread off=16777216 len=65536 -> reply cmd=... error=0 resid=65536 aux=65536 — an "error-free" reply whose 64KB aux equals the previous process's physio buffer (the secret image block), verified by md5.

On the fix kernel the same command returns aux=0.

DF-2876 VERDICT

Status: reproduced (leak — deterministic cross-process /

cross-device kernel-mediated info leak to the dmsg peer)

Guest: DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (env.txt).

What was run

run_f3.sh: 1. root creates vn0 backed by a 16MB urandom image (the "secret"), 2. root seeds the shared pbuf-mem pool: dd if=/dev/vn0 of=/dev/null (physio → getpbuf_mem → the KVA arena holds the secret, sys/kern/kern_physio.c:43), 3. the dmsg peer issues BLK_READ at exactly EOF (offset = media size) on the same disk.

Observed (stock kernel), 3 runs

• run 1: reply error=0 resid=65536 aux=65536; the 64KB aux is byte-identical to the secret image block (md5 7081aa33… both) — the read transferred nothing yet returned a previous process's physio buffer in full.
• run 2: aux starts fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c … — the boot disk's MBR boot code, leaked through vn0's channel (cross-device disclosure; the arena is global).
• run 3: aux = 0xAA fill — stale dmsg write aux from earlier testing.

Root cause: diskiodone sets data = bp->b_data; bytes = bp->b_bcount before checking B_ERROR/b_resid (sys/kern/subr_diskiocom.c:594-597) and attaches the buffer unconditionally (:651-655). An EOF read on a vnode-backed vn disk returns success with untouched resid (vnstrategy copies auio.uio_resid to b_resid, sys/dev/disk/vn/vn.c:337,385-389), so the stale arena contents ship to the peer. The same happens for B_ERROR completions (driver never touched the buffer).

Impact ceiling: any dmsg peer can repeatedly harvest up to MAXPHYS of the most recent raw-I/O buffer of ANY process on the machine (backups, fsck raw scans, other cluster nodes' disk traffic through diskiocom itself). Cluster-remote (AV:A) or local privileged.

Fix validation

fix.diff (no aux on B_ERROR; only completed bytes on short reads) applied, kernel rebuilt, PoC re-run: eofread … aux=0 — leak dead (run.fix.log).