DF-2303 — latent negative-length bcopy in fwohci_arcv split-header pullup

What this is

Verification pack for finding DF-2303 (sys/bus/firewire/fwohci.c:2729-2735). Low / speculative, latent memory-corruption landmine. Claim: in the split-header reassembly path, rlen is recomputed as sizeof(pktbuf) - rlen (fwohci.c:2732); if the previous-buffer fragment exceeded sizeof(pktbuf)=16 the new rlen goes negative and the diagnostic at 2733-2734 does NOT skip the following bcopy(db_tr->buf, p, rlen) (fwohci.c:2735), whose negative int becomes a huge size_t.

Verdict (short)

NOT REPRODUCIBLE FROM PACKET INPUT — and the battery proves it; the landmine itself is REAL and catastrophic when the state is injected:

• (A) Reachability battery (run.log): every header straddle the real parser can produce was driven through the REAL fwohci_arcv split-header path (firewire_debug on, "rlen=%d, offset=%d" printed by the real code at fwohci.c:2721-2723): WREQB (16B hdr): F = 4, 8, 12 -> rlen_old = 4/8/12 WRES (12B hdr): F = 4, 8 -> rlen_old = 4/8 All rlen_new = 16 - rlen_old in [4,12] > 0. No "why rlen < 0". Guest up after all runs.
• (B) Impossible-state injection (run2303b.log, panic.txt): with buf_offset forced to -(4096-24) (rlen_old = 24 > 16 — a state no packet stream can produce), the real code printed "why rlen < 0" and the very next bcopy hit the stack guard page: panic: vm_fault: fault on stack guard with memmove in the trace — the negative-length bcopy is a live stack-smash primitive.

Why rlen_old > 16 is unreachable (line-accurate invariant)

1. buf_offset becomes negative ONLY at fwohci.c:2762 (buf_offset = -buf_offset), immediately after fwohci_arcv_swap returned -hlen (hlen > len) for a parse at position X in buffer N (buf_offset = ld - buf = X at that point, set by fwohci.c:2800).
2. At out: (fwohci.c:2855) if resCount != 0, line 2871 OVERWRITES buf_offset with a positive value, destroying the split state — so the split-header branch (2712ff) is entered only when resCount was 0, i.e. the buffer was full and len at the failing parse was psize - X = rlen_old.
3. The parse failed with hlen > len, and hlen = tinfo[tcode].hdr_len <= 16 for every tcode arcv_swap accepts (fwohci.c:2601-2617); therefore rlen_old < hlen <= 16 whenever the state survives. Additionally every AR packet consumes a multiple of 4 bytes (12/16-byte headers + 4-byte trailer + quadlet-rounded payloads) and fwohci_arcv_swap has no STREAM case (tcode 0xa rejected, "Unknown tcode 10"), so F is quadlet-aligned: the battery set {4,8,12} is the complete reachable space for a 4096-byte buffer.

The battery mechanically confirms each element of the invariant ("split header" print, "rlen=F, offset=-X" print, clean completion).

Fix

fix.diff turns the diagnostic into a guard (drop + goto out). A/B validated: the SAME injected state on the fixed kernel prints the drop message and survives instead of panicking.

Reachability honesty

As filed: latent/unreachable today. The finding text itself says "currently unreachable ... latent landmine if control flow changes" — this verification upgrades that claim from speculation to mechanical proof (battery + invariant + demonstrated consequence).

DF-2303 VERDICT — latent negative-length bcopy in fwohci_arcv

• finding: DF-2303, fwohci.c:2729-2735 (split-header pullup, rlen = sizeof(pktbuf) - rlen; unguarded bcopy with negative len)
• status: not_reproduced (from packet input; proven unreachable)
• impact class: corruption (the code defect is a live stack-smash primitive — demonstrated by state injection — but no attacker- reachable input produces the state on this tree)
• confidence: certain (as a negative result)

(A) Battery — the complete reachable split-header space

Rig: REAL fwohci_db_init + REAL fwohci_rx_enable on arrq (psize=4096, ndesc=1, ndb=128; per-tr buffers allocated by the real fwohci_add_rx_buf), received-DMA state fabricated exactly as OHCI AR DMA would leave it (quadlet-aligned WRES(16B)/WREQB(20B) filler chain up to X, split packet-B header at X = psize - F, resCount/status in desc.res), then REAL fwohci_arcv(sc, dbch, -1) with firewire_debug=1.

Observed from the real code (console/dmesg, run.log):

FWOH: ARCV NATURAL tcode=1 hdr=16 F=4  X=4092 -> REAL fwohci_arcv
split header
rlen=4, offset=-4092
... F=8: rlen=8, offset=-4088 ... F=12: rlen=12, offset=-4084
WRES F=4: rlen=4, offset=-4092 ... F=8: rlen=8, offset=-4088

rlen_new = 16 - rlen_old in [4,12] — strictly positive; reassembly completed for every case (buf_offset positive after, pdb_tr cleared); no "why rlen < 0"; guest stable after all runs.

Why this is the COMPLETE set: quadlet alignment (packet boundaries are multiples of 4) + headers of 12/16 bytes + hlen>len split criterion + the resCount==0 requirement implied by the 2871 clobber (see README) => F in {4,8,12} for 16-byte headers, {4,8} for 12-byte headers. An earlier battery variant that tried STREAM fillers proved arcv_swap rejects tcode 0xa outright ("Unknown tcode 10", fwohci.c:2614-2618) — STREAM never reaches the split path at all.

(B) Injection — the landmine is real

fwpoc ctl arcv 1 0 0 4072 sets dbch->buf_offset = -4072 (rlen_old = 24 > 16 — impossible per (A)) and calls the real fwohci_arcv:

FWOH: ARCV INJECT buf_offset=-4072 -> rlen_old=24 (EXCEEDS 16)
why rlen < 0                                   <- fwohci.c:2734
panic: vm_fault: fault on stack guard, addr: 0xfffff80116b51000
memmove() at memmove+0x24f <- fwoctl_ioctl (fwohci_arcv inlined)

(panic.txt) — first bcopy overflows pktbuf[16] on the stack, second bcopy receives (size_t)-8 and writes until the stack guard page: catastrophic kernel memory corruption IF the state is ever reachable.

Bottom line

The filed claim is exactly confirmed: the code is a latent landmine ("developer comment shows awareness without understanding consequence") that is unreachable from packet input on this tree. Recommend the one-line guard anyway (defense in depth; any future change to the 2871 clobber or to busdma resCount semantics re-arms it), plus note that the 2871 overwrite itself silently discards a legitimate split-header state (separate correctness bug, out of scope of this finding).

Fix validation (A/B)

fix.diff: if (rlen < 0) { kprintf drop; pdb_tr=NULL; buf_offset=0; goto out; }. Fixed kernel + identical injection: drop message printed, NO panic, guest up (run_fixed.log).

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.