DF-2298 — Heap OOB read/write via zero-length segment array from integer overflow in n

File: sys/bus/firewire/fwdma.c:145-166 + sys/bus/firewire/fwdma.h:59-75 Verdict: REPRODUCED — OOB read of a groom-controlled pointer + production fw_write landing 2048 attacker-chosen bytes at the chosen kernel address.

Claim

FW_SSTBUF (no validation, fwdev.c:504-506) → fwdev_allocbuf (fwdev.c:109) computes n = b->nchunk * b->npacket as an int multiply. For nchunk = npacket = 0x10000 the product wraps to 0 mod 2^32. fwdma_malloc_multiseg(fc, 4, 512, 0, ...) then computes nseg = howmany(0, 4096/512) = 0, kmallocs only the 32-byte struct fwdma_alloc_multi header (fwdma.c:162-163) and returns it as success with a zero-length seg[] array. fwdev_allocbuf stores the original nchunk/npacket in the queue and marks FWXFERQ_EXTBUF, so production fw_write/fw_read reach fwdma_v_addr() (fwdma.h:59-66), which reads am->seg[0].v_addr — 8..24 bytes past the 32-byte allocation — and uiomove()s attacker iso data to that stale/groomed pointer.

How to build / run (no FireWire hardware needed — KLD harness)

The harness compiles the unmodified production firewire.c + fwdma.c + fwdev.c into df229x.ko (DF-5613 pattern) and drives the real fw_ioctl / fw_write paths. Test 2:

1. sprays the 32-byte kmalloc zone with chunks whose every qword is the victim pointer, then punches holes (every 2nd chunk freed);
2. FW_SSTBUF{tx:{0x10000, 0x10000, 512}} + FW_STSTREAM → the zero-seg am lands in a hole → the OOB am->seg[0].v_addr (at am+40) reads back the pointer we chose;
3. one production fw_write() (fwdev.c:388-392) uiomoves the 4-byte iso header + len (2044) payload bytes of attacker data to that address.

# guest, root, fresh `vm.sh reset with-src`
cd /root/df229x && sh build.sh && kldload ./df229x.ko
sysctl kern.df229x_test=2 && sysctl kern.df229x_status

Expected (baseline, reproduced)

df2298/a1: am (32-byte kmalloc, nseg=0) -> OOB am->seg[0].v_addr = 0xfffff801187ea000
           (read at am+40); groom target = 0xfffff801187ea000
df2298/a1: fw_write err=0; victim page now: "" / "DF2298-OOB-WRITE"
df2298/a1: CONTROLLED WRITE CONFIRMED: attacker iso payload ... landed at the
           groom-chosen kernel address ... via the OOB-read seg[0].v_addr
kern.df229x_status: DF-2298 REPRODUCED: ... OOB-read-to-arbitrary-write

(Groom hit 4/4 attempts across two boots. Without the groom the same OOB read hands fw_write an uncontrolled kernel pointer — a wild write/panic.)

Expected (fix.diff applied, module rebuilt — fix_run.log)

df2298/a*: STSTREAM err=22 -- bufspec rejected, no zero-seg allocation
kern.df229x_status: DF-2298 nchunk=npacket=0x10000: STSTREAM err=22 (rejected, no write)
kern.df229x_status: DF-2298b npacket=0: STSTREAM err=22      (trivial n=0 variant)
kern.df229x_status: regression OK: legit bufspec still works

Files

df229x.c (harness; test 2 = this finding, test 4 = trivial npacket=0 variant), Makefile + shim/, build.sh, run_bootA.sh / run_fix.sh, run.log (decisive baseline), fix_run.log, baseline_build.log / fix_build.log, env.txt, fix.diff, VERDICT.md, manifest.json, verdict.json

DF-2298 — VERDICT

Status: REPRODUCED (impact: memcorrupt — OOB read of a heap-adjacent, groom-controlled pointer feeding a production uiomove write of fully attacker-chosen bytes: a demonstrated write-what-where class primitive). Confidence: certain.

Reachability trace (production code, this tree, today)

1. fwdev.c:504-506 — FW_SSTBUF copies struct fw_isobufreq (userspace unsigned int triples, firewire.h:50-56) unvalidated.
2. fwdev.c:103-109 — fwdev_allocbuf: kmalloc(sizeof(fw_bulkxfer) * b->nchunk) (48 * 0x10000 = 3 MB, fine), then fwdma_malloc_multiseg(fc, 4, roundup2(512,4), b->nchunk * b->npacket, ...). The element count is an int multiply: 0x10000 * 0x10000 == 0 (mod 2^32).
3. fwdma.c:157-166 — esize=512 ≤ PAGE_SIZE → ssize = rounddown(4096,512) = 4096, nseg = howmany(0, 8) = 0; am = kmalloc(32 + 24*0) — only the 32-byte header — am->nseg = 0, the per-segment loop (fwdma.c:193-203) is skipped, and am is returned as success.
4. fwdev.c:116-134 — the original bnchunk=0x10000, bnpacket=0x10000 are stored, 65536 fw_bulkxfer entries initialized, queue flagged FWXFERQ_EXTBUF. From userspace the ioctl returned 0: nothing looks wrong.
5. fwdev.c:388-392 — fw_write: fp = fwdma_v_addr(it->buf, poffset+queued); fwdma.h:59-66 computes am->seg[0/4096].v_addr — seg[0] begins at am+32, i.e. entirely past the 32-byte allocation; v_addr is the qword at am+40, read from the adjacent 32-byte slab chunk. Then uiomove(fp, 4) + uiomove(fp->payload, fp->len) write attacker bytes to that pointer. (fw_read, fwdev.c:321-330, is the arbitrary-read mirror.)

What was run (decisive evidence, run.log)

Production path driven end-to-end with the OOB pointer proven controlled before any write fires:

• 512×kmalloc(32, M_FW) groom chunks each pre-filled with the victim pointer, every 2nd freed → am's kmalloc(32, M_FW) (fwdma.c:162) lands in a hole;
• df2298/a1: STSTREAM OK (err=0) ... nseg=0 ssize=4096 esize=512 bnchunk=65536 bnpacket=65536 — the overflow-to-zero state itself;
• OOB am->seg[0].v_addr = 0xfffff801187ea000 (read at am+40); groom target = 0xfffff801187ea000 — the OOB read returns exactly the pointer we planted (groom hit 4/4 across two boots: 3/3 on the first run's attempts, 1/1 decisive);
• production fw_write → err=0; victim page now: "" / "DF2298-OOB-WRITE" — header at victim[0..4) (NUL bytes print empty), payload DF2298-OOB-WRITE!… at victim+4;
• CONTROLLED WRITE CONFIRMED: attacker iso payload (header + 2044 bytes) landed at the groom-chosen kernel address.

Primitive characterization (write-capable bug → what it is)

• What: 4 semi-constrained bytes (iso stream header: len:16 bounds the following write) then up to len (u16, ≤65535) fully attacker-chosen bytes per packet, repeatable per chunk/packet.
• Where: any address the attacker can plant in the adjacent 32-byte kmalloc chunk — i.e. arbitrary kernel address (demonstrated: the write landed precisely on the pre-registered victim page; the harness never fires the write unless the OOB read provably returned the planted pointer).
• Read mirror: fw_read (fwdev.c:321-330) uiomoves out of the same OOB-derived pointer → arbitrary-read shape.
• uid=0 route: on the no-KASLR/no-SMAP guest, spray the 32-byte zone with the address of any known writable function pointer / ops table (fixed kernel addresses), overwrite it via the iso payload, trigger the call — or use the read mirror to walk allproc → own p_ucred and zero the uids with the write. Full uid=0 chain not constructed this run: entry requires a FireWire controller's /dev/fw* node (0660 root:operator), which the QEMU guest does not have — same evidence-class standard as DF-5413/DF-5548/DF-5613 (hardware-gated entry, primitive proven on production code).
• Without grooming, the same OOB read hands uiomove an uncontrolled kernel qword → wild write → panic (trivially reachable DoS).

Reconciliation with the pass-2 negative note

Pass 2 killed only the other sub-variant ("size_t wrap of sizeof(fwdma_seg)*nseg unreachable on 64-bit … 32-bit-only"). The finding's primary claim — int product nchunk*npacket wrapping to 0 → zero-length seg[] → OOB access — is 64-bit reachable and reproduced here on x86-64. Also note npacket=0 reaches the identical n=0 state without any overflow (tested: rejected by the fix, DF-2298b err=22).

Fix validation (fix.diff, applied to guest /usr/src, module rebuilt)

• Overflow variant 0x10000×0x10000 → STSTREAM err=22, no zero-seg allocation, no write (it=0 buf=0 bulkxfer=0) — the fwdev_allocbuf hunk rejects npacket > 0x7fffffff / nchunk before the multiply feeds fwdma_malloc_multiseg.
• Trivial variant npacket=0 → err=22.
• Hard boundary: direct fwdma_malloc_multiseg(esize=512, n=0) → NULL, no trap (the fwdma.c hunk), so no caller can reach the zero-length seg[] state even if a future caller forgets validation.
• Regression: legit {4,8,2048} still allocates and streams. Guest alive (fix_run.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.