# 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

```c
	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.
