DF-2302 — fwohci_db_free NULL deref on partial bus_dmamap_create failure

What this is

Verification pack for finding DF-2302 (sys/bus/firewire/fwohci.c:1236 failure path -> fwohci_db_free, fwohci.c:1157-1182). Low / local DoS panic. Claim: if bus_dmamap_create() fails at loop iteration K, fwohci_db_init fakes FWOHCI_DBCH_INIT (fwohci.c:1238) and calls fwohci_db_free, whose loop (fwohci.c:1166-1167) iterates idb < ndb over a queue that only holds K entries -> STAILQ_NEXT yields NULL -> db_tr->buf/db_tr->dma_map dereference of NULL -> kernel panic.

Verdict (short)

REPRODUCED — kernel panic through 100% real code:

bus_dmamap_create failed                              <- fwohci.c:1237
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x18                          <- NULL + offsetof(fwohcidb_tr, dma_map)
fwohci_db_free.part.7() at ...  <- fwohci.c:1166-1174
fwoctl_ioctl() ...
panic: page fault

The panic (panic.txt) came from the REAL fwohci_db_init -> REAL bus_dma failure -> REAL fwohci_db_free, on the verbatim fwohci.c TU harness kernel. Trigger: the 32-bit DMA bounce window (4 MB, modeling a >4 GB-RAM host where the OHCI 32-bit window is a scarce resource) exhausted so alloc_bounce_pages -> contigmalloc fails (busdma_machdep.c:412) inside bus_dmamap_create.

Rig mechanics (how the real failure was produced)

• The fabricated parent bus_dma tag has lowaddr=0x400000 (4 MB). On a

  4GB-RAM host the stock fwohci tag (lowaddr=BUS_SPACE_MAXADDR_32BIT, fwohci.c:1197) has exactly this character: bounce pages must come from below lowaddr.

• fwpoc ctl memeat F ch: pins EVERY free page of [0,4MB) with contigmalloc (M_WAITOK — same 3-pass reclamation power as the bus_dmamap_create path, sys/vm/vm_contig.c:300-376), frees F pages, then calls the real fwohci_db_init on the channel.
• Repeated rounds convert window pages into permanent zone bounce pages (each successful db_init permanently parks 1-2 pages in the busdma zone). After ~57 rounds the window is fully pinned (ate=0); the final round runs db_init with zero free window pages -> the first bus_dmamap_create fails -> db_free -> panic (run.log has the ate-by-round history: 128 -> 0).

K-quantification (DF 6.5 busdma behavior found during verification)

bus_dmamap_create() only returns ENOMEM while BUS_DMA_MIN_ALLOC_COMP is clear — after the first successful create the else { error = 0; } at busdma_machdep.c:423-425 clears later alloc failures. Consequence: on this tree the reachable form of the bug is K=0 (first create fails, queue empty, first loop body derefs NULL — fault VA 0x18 = offsetof(dma_map)). The K>0 form (partial queue) needs a first-create success followed by a later failure, which current busdma masks — but the loop defect is identical, and the fix guards both.

Reachability honesty

Requires FireWire hardware + memory pressure in the 32-bit DMA window during channel (re)initialization (controller init, iso channel setup). Attacker role: unprivileged users can generate the memory pressure; the init window belongs to open/enable paths reachable from the operator group. Severity Low as filed (panic/DoS only).

Fix

fix.diff: NULL-safe loop (db_tr != NULL && idb < dbch->ndb) plus a guard on the tail kfree(STAILQ_FIRST(...)) (kfree(NULL) panics on DF, kern_slaballoc.c:1409 — the tail free otherwise just moves the panic). Residual (documented): the K=0 error path leaks the one kmalloc'd db_tr array because db_init loses its base pointer across the loop; fixing that cleanly requires keeping the array head in db_init (not done to keep the patch minimal). A/B validated: fixed kernel survives the identical trigger with a clean unwind (see run_fixed.log).

DF-2302 VERDICT — NULL deref in fwohci_db_free after partial db_init

• finding: DF-2302, fwohci.c:1236-1241 (bus_dmamap_create failure -> faked FWOHCI_DBCH_INIT -> fwohci_db_free) and fwohci.c:1166-1174 (the unguarded loop)
• status: reproduced (kernel panic, fatal trap 12, fault VA 0x18)
• impact: panic (denial of service; requires memory pressure in the 32-bit DMA window during FireWire channel init on real hardware)
• confidence: certain

Reproduction narrative

1. Rig: fwohci.c TU harness (same as DF-2300); fabricated parent bus_dma tag with a 4 MB lowaddr models the >4 GB-RAM host on which the stock fwohci tag (lowaddr = BUS_SPACE_MAXADDR_32BIT, fwohci.c:1197) must bounce. All busdma code executed is the real stock platform code (busdma_machdep.c, vm_contig.c).
2. fwpoc ctl memeat 2 3: eat the whole [0,4MB) window with M_WAITOK contigmalloc (same 3-pass reclamation power the map_create path has), free 2 pages, run REAL fwohci_db_init on arrs.
3. Rounds 1..56: db_init succeeds; each round permanently converts 1-2 window pages into busdma-zone bounce pages (ate declines 128 -> 0 monotonically, run.log).
4. Final round (ate=0, freed=0): inside the real fwohci_db_init loop the FIRST bus_dmamap_create of dbch->dmat hits alloc_bounce_pages -> contigmalloc -> NULL (busdma_machdep.c:412, vm_contig.c:560-580) -> ENOMEM -> fwohci.c:1237 prints "bus_dmamap_create failed" -> fwohci.c:1238 fakes INIT -> fwohci_db_free -> fwohci.c:1166 loop starts with db_tr = STAILQ_FIRST = NULL (queue empty, K=0) -> first body evaluates db_tr->dma_map (compiled first; fault VA 0x18 = offsetof(struct fwohcidb_tr, dma_map), fwohcireg.h:330-337) -> fatal trap 12 -> panic. Serial capture verbatim in panic.txt (backtrace: fwohci_db_free.part.7 <- fwoctl_ioctl; the .part.7 is GCCs clone of the static fwohci_db_free from the TU-compiled verbatim fwohci.c).

K-quantification (new line-accurate knowledge from this run)

busdma_machdep.c:412-425: after the first successful create sets BUS_DMA_MIN_ALLOC_COMP, the else { error = 0; } clears subsequent alloc_bounce_pages failures. Only the FIRST map_create of a tag can return ENOMEM. Hence on this tree the reachable defect form is K=0 (empty queue, fault at iteration 0). The originally-filed K>0 form (partial queue, NULL after the last queued entry) is masked by the busdma quirk today but is the same unguarded loop; any future busdma change re-arms it. The fix guards both forms.

Fix validation (A/B)

fix.diff: * loop condition db_tr != NULL && idb < dbch->ndb (stops at the real queue tail), * if (db_tr != NULL) kfree(db_tr, M_FW); on the tail free — WITHOUT this, the fixed loop merely moves the panic to kfree(NULL) (kern_slaballoc.c:1409 panics on NULL), which I verified while authoring the patch. Fixed kernel (FWO #4): identical trigger (full window exhaustion + memeat rounds) -> "bus_dmamap_create failed" printed, db_free unwinds without panic, guest stays up, repeated rounds keep surviving (run_fixed.log). Residual K=0 leak of the db_tr array documented in README (db_init loses the array base across the loop).

Reachability

Hardware + operator-group (channel setup) + 32-bit-DMA-window memory pressure. Unprivileged users contribute the pressure; the panic is local DoS. No privilege escalation path — NULL-deref only.

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.