DF-1035 — VERDICT

Verdict

NOT REPRODUCED (live) — bug CONFIRMED via code trace, fix.diff compiles + boots cleanly.

The stale-segment-index bug in bus_dmamap_load_uio is real and the cited line numbers are exact. Unlike the other four findings in this batch, the vulnerable function IS compiled into the audit guest's running kernel (verified via nm /boot/kernel/kernel → ffffffff80c1b830 T bus_dmamap_load_uio). However, the three in-tree callers (mpr.c, mps.c, isp_pci.c) are SAS/SCSI/fabric HBA drivers, none of which attach to the QEMU guest's PCI bus. The bug is therefore compiled-in but unreachable on this guest and reachable on any host that loads one of those three HBAs and submits a multi- iovec uio whose first iov maps more than half of dmat->nsegments DMA segments.

Mechanism (code trace)

bus_dmamap_load_uio() at sys/platform/pc64/x86_64/busdma_machdep.c:929-1017 iterates a uio's iovecs and calls _bus_dmamap_load_buffer() for each:

• busdma_machdep.c:961-962 c segs = segments; nsegs_left = dmat->nsegments;

• busdma_machdep.c:988-990 (per iovec) c error = _bus_dmamap_load_buffer(dmat, map, addr, minlen, segs, nsegs_left, pmap, flags, &lastaddr, &nsegs, first);

• busdma_machdep.c:994-997 c if (error == 0) { nsegs_left -= nsegs; segs += nsegs; } Between iterations, segs is advanced and nsegs_left is shrunk. But &nsegs (passed as segp) is NEVER reset — it stays an absolute count.

In _bus_dmamap_load_buffer() (busdma_machdep.c:583-760), the in/out parameter *segp is treated as a 1-based ABSOLUTE index into the array passed as the segments parameter:

• busdma_machdep.c:662 c KKASSERT(*segp >= 1 && *segp <= nsegments);

• busdma_machdep.c:663-664 c seg = *segp; sg = &segments[seg - 1];

On the 2nd iovec: * *segp (= &nsegs) is the absolute count from the first iov (e.g. M). * The local segments parameter is original_segments + M (because the caller advanced it). * The local nsegments parameter is nsegs_left = N - M. * The KKASSERT(M <= N - M) fires when the first iov consumed MORE than half the budget (i.e. M > N/2). On default GENERIC (INVARIANTS on) this is a kernel panic. On a noinv kernel the KKASSERT is stripped, and the next iteration computes sg = &local_segments[M-1] = &original_segments[M + M - 1] — an OOB write past the segments array (which is either an 8-slot stack cache or a heap alloc sized to dmat->nsegments).

The correct reference behaviour is bus_dmamap_load_mbuf_segment() at busdma_machdep.c:869-923, which passes CONSTANT (segs, maxsegs) on every call and lets *segp be the absolute end-index.

Why it does not reproduce on this guest

There is no caller to invoke bus_dmamap_load_uio with a multi-iovec uio on the audit guest.

Exploit chain

none — the bug is unreachable on this guest. On a host with one of the three HBAs, the primitive is a kernel panic (INVARIANTS) or an OOB write of bus_dma_segment_t (16-byte) records past the segments array (noinv). The mps/mpr callers build the uio from a SCSI sglist whose count is attacker-influenced via /dev/pass*, so unprivileged users with pass-device access could in principle shape the iovec count.

Fix

fix.diff matches bus_dmamap_load_mbuf_segment()'s pattern: pass CONSTANT (segments, dmat->nsegments) to every _bus_dmamap_load_buffer call, drop the now-unused segs / nsegs_left variables, and treat nsegs as the absolute end-index in the final callback (which _bus_dmamap_load_buffer already guarantees is >= 1, satisfying the historical "minimum one segment even if 0-length buffer" requirement). The inner function returns EFBIG when segments are exhausted, so termination is preserved.

Fix validation

This is the only one of the five findings where the fix lands IN the kernel binary, so we ran a full single-fix kernel build:

• fix.diff applies cleanly to /usr/src/sys/platform/pc64/x86_64/busdma_machdep.c with patch -p1 (3 hunks all succeeded).
• make -j6 nativekernel KERNCONF=X86_64_GENERIC rebuilt the kernel with the fix; busdma_machdep.c recompiled with -Werror cleanly (fix_build.log excerpt shows the cc line and the subsequent linking kernel.debug step, no errors).
• Installed kernel.stripped → /boot/kernel/kernel (sha256 39ed9f4e937b0bc211e0070ea7643b080c0f3a85fe3bbd4758f901c9e9d8b4e7).
• Booted the patched kernel cleanly: DragonFly 6.5-DEVELOPMENT #1: Sun Jul 19 15:59:52 UTC 2026.
• Guest was healthy after boot: pciconf -l, camcontrol devlist, and all 5 PoC harnesses ran cleanly on the patched kernel.
• Not live-tested against the actual bug (no HBA to invoke the path), but the regression-test of "kernel boots and is functional with the fix" is clean.

fix_status: not_testable (no live trigger available; the patched-kernel boot + compile is the strongest validation possible without HBA hardware).

PoC changes

The finding folder was empty; this run authored: - poc.c — documentation harness - fix.diff — the verified fix - build.sh, run.sh, build.log, run.log, env.txt, fix_build.log, manifest.json, VERDICT.md