DF-5117 evidence pack

Finding: dmamap_cb (dcons_crom.c:126-153) continues after a bus_dmamap_load error — stores uninitialized-stack segments[0].ds_addr into dcons_paddr, prints those kernel-stack bytes to console, wires dcons_conf globals for a failed map, and the garbage address is published into the FireWire ConfigROM (dcons_crom.c:120-121). Attach ignores all three bus_dma return values. DF's bus_dmamap_load calls the callback even on error (busdma_machdep.c:804).

Status: untested / Info — precondition (load failure on a valid contig buffer with WAITOK forced) is unreachable on DF/amd64; no FireWire hardware on the guest. Hardening only.

Contents: VERDICT.md (trace), trigger.sh (documents unreachable precondition), env.txt (guest), fix.diff (error return + checked attach).

DF-5117 — dcons_crom dmamap_cb continues after bus_dmamap_load error: garbage physical address published to the FireWire ConfigROM + uninitialized stack bytes printed to console

Verdict: UNTESTED (and practically unreachable on this platform) — Info/hardening. The defect is certain in code; the triggering load failure is ~impossible on DF/amd64 for this buffer.

Where

• sys/dev/misc/dcons/dcons_crom.c:126-153 (dmamap_cb)
• sys/dev/misc/dcons/dcons_crom.c:171-185 (dcons_crom_attach — all three bus_dma return values ignored)
• DF bus_dma semantics: sys/platform/pc64/x86_64/busdma_machdep.c:766-807 — bus_dmamap_load invokes the callback at :804 even when error != 0 (only EINPROGRESS defers), with segments pointing at the caller's uninitialized cache_segments[] stack buffer (:771) and nsegs merely initialized to 1 (:774).

The defect

    if (error)
        kprintf("dcons_dmamap_cb: error=%d\n", error);   /* prints... */

    sc = (struct dcons_crom_softc *)arg;
    sc->bus_addr = segments[0].ds_addr;   /* ...but DOES NOT RETURN */
    ...
    dcons_conf->dma_tag = sc->dma_tag;    /* wires globals for a failed map */
    dcons_conf->dma_map = sc->dma_map;
    dcons_paddr = sc->bus_addr;           /* garbage published */

On a load error the callback:

1. reads segments[0].ds_addr — uninitialized kernel stack — and both prints it to the console (bus_addr 0x%jx, dcons_crom.c:137-138: an 8-byte kernel-stack disclosure to dmesg) and stores it into the module global dcons_paddr;
2. that garbage dcons_paddr is then published into the local ConfigROM by dcons_crom_post_busreset (dcons_crom.c:120-121, DCONS_CSR_KEY_HI/LO) for any FireWire peer — the peer's dcons client then reads/writes the wrong physical address;
3. dcons_conf->dma_tag/dma_map are wired for a map whose load failed — bus_dmamap_sync on an unloaded map (silent coherency loss or, with bpages, wrong bounce handling);
4. attach still returns 0 — the driver claims healthy.

dcons_crom_attach (dcons_crom.c:171-185) ignores the return of bus_dma_tag_create, bus_dmamap_create and bus_dmamap_load; on DF/amd64 the tag create is M_INTWAIT/ALLOCNOW-backed and bus_dmamap_load forces WAITOK (:782-783) over a valid contigmalloc buffer, so failure needs pathological conditions — hence Info, not higher.

Fix

Early-return on error in dmamap_cb and check/propagate the three returns in attach (fail the attach with unwind) — fix.diff.

Why no PoC run

Requires a FireWire controller (none on the guest — env.txt) and a bus_dmamap_load failure that current DF busdma cannot produce for this buffer. Pure hardening.

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.