DF-2296 — FW_ASYREQ unbounded pay_len bcopy over-read (+ discovered sibling write bug)

Verdict (short)

REPRODUCED on the stock fwdev.o/firewire.o binaries — core claim confirmed; plus a worse sibling bug was discovered on the same line (see Sibling finding below — flagged for a new DF-ID by the orchestrator).

Claim proven: * pay_len = MAX(0, asyreq->req.len - tinfo->hdr_len) (fwdev.c:530) is never bounded by sizeof(asyreq->data) (2048 bytes). With req.len 4096 (u16 max 65535), the bcopy at fwdev.c:560 copies 4080 bytes from asyreq+36 — 2032 bytes past the 2084-byte M_IOCTLOPS staging buffer (sys_generic.c:675) — into the xfer payload area. * S400 ordering proven: with fc->maxrec=10 (fwohci.c:521: fc->maxrec = fc->speed + 8, S400 speed 2 → MAXREC 2048 — note: the original claim said 512; actual stock S400 gate is 2048 quadlet bytes), fw_asyreq rejects with send.pay_len > maxrec (firewire.c:210) and the ioctl returns EINVAL — but the bcopy at fwdev.c:560 runs unconditionally BEFORE fw_asyreq (fwdev.c:565), dmesg confirms the gate line after the copy executed. * Full path on big-maxrec: with fc->maxrec=11 (S800 speed 3 → MAXREC 4096), the same request completes the entire stock path — fw_asyreq → fw_asystart → the interposed OHCI TX start records a 4080- byte "wire" payload snapshot. On real hardware those bytes (including the 2032 bytes read past the ioctl buffer) are DMA'd onto the bus. fwohci max maxrec is 11 (speed+8, MAX_SPEED 3) → wire disclosure up to 2048 bytes of adjacent kernel heap on S800-capable controllers.

Fix validated: pay_len > sizeof(asyreq->data) → EINVAL (before any alloc/copy); legit req.len=2064 (pay_len 2048 == capacity) still runs the full path identically (rc=0, wire snapshot 2048 bytes).

Sibling finding discovered during verification (NEW — needs an ID)

fwdev.c:561: bcopy(..., (void *)&xfer->send.payload, pay_len); — copies into the ADDRESS OF the payload pointer field, not the payload buffer (FreeBSD's original is (void *)xfer->send.payload). For ANY FW_ASYREQ block request this smashes the tail of struct fw_xfer (send.payload/pay_len/spd, recv.hdr/payload/pay_len, mbuf, link, malloc — offsets published by the rig: send.payload=+80 … malloc=+144, sizeof=152) and overruns the 160-class fw_xfer allocation by up to ~63KB with fully user-controlled packet bytes (a kernel heap overwrite primitive reachable by the same operator-group ioctl, no peer needed). Three distinct panics were captured while walking this path stock (GPF in _kfree freeing the smashed send/recv.payload, page fault in pmap_kvtom), and behavioral control of the smashed fields was demonstrated (planted recv.hdr tcode steered the response path; planted lenval steered the MAXREC gate). One-character fix: drop the &. See smash_panic_gfp_kfree.txt / dmesg_phaseA_gate.txt / VERDICT.md.

Files

• poc_2296.c — trigger with stock-compatible field planting (keeps the smashed fw_xfer tail valid so the full stock path completes)
• run_2296.sh + run_2296.log — A (S400 reject-after-copy), B (S800 full path), C (response-path write variant) + spray canary analysis
• dmesg_phaseA_gate.txt, dmesg_serial_run.txt, smash_panic_gfp_kfree.txt
• spraydump.{A1,A2,B1,B2,C}.txt — canary dumps
• run.legit_baseline.log, fix_run.log — A/B evidence
• fix.diff — combined fix (this finding: pay_len bound)

DF-2296 VERDICT — REPRODUCED (kernel heap over-read into TX payload; wire disclosure on S800)

Claim and code (line-accurate)

fw_ioctl FW_ASYREQ (fwdev.c:521-587):
526:    fp = &asyreq->pkt;                     /* offset 20 in struct */
527:    tinfo = &sc->fc->tcode[fp->mode.hdr.tcode];
529:    if ((tinfo->flag & FWTI_BLOCK_ASY) != 0)
530:        pay_len = MAX(0, asyreq->req.len - tinfo->hdr_len);
     /* req.len: unsigned short — NEVER bounded by sizeof(asyreq->data)
      * (2048 bytes at struct offset 36; struct is 2084 bytes) */
532:    xfer = fw_xfer_alloc_buf(M_FWXFER, pay_len, PAGE_SIZE);
558:    bcopy(fp, (void *)&xfer->send.hdr, tinfo->hdr_len);
559:    if (pay_len > 0)
560:        bcopy((char *)fp + tinfo->hdr_len,
561:            (void *)&xfer->send.payload, pay_len);
     /* SOURCE: asyreq+20+16 = asyreq+36 = data[0]; pay_len up to 65519
      * reads up to ~63KB past the 2084-byte ioctl staging buffer
      * (kmalloc(IOCPARM_LEN, M_IOCTLOPS), sys/kern/sys_generic.c:675)
      * into adjacent kernel heap */
565:    if ((err = fw_asyreq(sc->fc, -1, xfer)) != 0)   /* MAXREC gate is
      * INSIDE fw_asyreq (firewire.c:210), i.e. AFTER the bcopy */

fw_asyreq (firewire.c:183-250):

210:    if (xfer->send.pay_len > MAXREC(fc->maxrec)) {
211:        kprintf("send.pay_len > maxrec\n");
212:        return EINVAL;

MAXREC(x) = 2 << x (firewire.h:73); stock controllers set fc->maxrec = fc->speed + 8 (fwohci.c:521), so S100/200/400/800 → 512/1024/2048/4096 bytes. (Correction to the original finding text: the S400 gate is 2048 bytes, not 512.)

Observed (baseline harness kernel, stock fwdev.o/firewire.o)

The rig plants field values into data[] that keep the (smashed, see sibling) fw_xfer tail valid so the unmodified stock path completes; see poc_2296.c header for the exact recipe and rig sysctls hw.fwh_off_* (exact kernel offsetof values).

• Phase A — S400 (maxrec=10), req.len=4096 (pay_len=4080): send.pay_len > maxrec printed (firewire.c:210), ioctl returns EINVAL — and this rejection is only reachable at fwdev.c:565, i.e. strictly AFTER the 4080-byte bcopy at :560-561 already executed (dmesg_phaseA_gate.txt, run_2296.log).
• Phase B — S800 (maxrec=11), same request: full stock path completes (rc=0): fw_asyreq → fw_get_tlabel → fw_asystart → the interposed OHCI AT-start: fwh: AT-START: 'wire' payload snapshot 4080 bytes (wire count=1). The payload that real hardware would DMA onto the FireWire bus contains, in its last 2032 bytes, whatever kernel heap followed the ioctl staging buffer. The staging buffer is exactly 2084 bytes; data[] ends at the buffer end; everything the bcopy read beyond index 2048 is adjacent kernel memory.
• Phase C — response-path write variant (supplementary): with an emulated 2304-byte peer block response, the response copies at fwdev.c:582-584 (bcopy(xfer->recv.payload, (char*)fp + hdr_len, MAX(0, req.len - hdr_len)) — note the EINVAL branch at :581 does NOT skip these copies) write req.len-16 bytes into the staging buffer at pkt+16 — 240 bytes past its end for recvpl=2304. Executed (rc=0) with canary-corruption detected (SPRAYCHK corrupt=1, badwords=576, dmesg_serial_run.txt); byte-attribution of the 240 bytes to a specific canary chunk could not be pinned down because the staging buffer's slab placement never landed adjacent to a monitored chunk within the runs performed (spraydump.C.txt shows monitored 2084-chunks intact; the corruption landed in the 160-class zone).
• Canary-attribution caveat (honest): the slab allocator's per-CPU magazines prevented deterministic placement of the fw_xfer next to sprayed 160-byte canaries (SPRAYCHK corrupt=0 for phases A/B in the final run; earlier runs showed corrupt=1 from the destination-side smash). The READ past the 2084-byte staging buffer is nonetheless proven: the copy length (4080) is twice the data[] capacity, the copy demonstrably executed (phase B full path; phase A gate order), and the source pointer (asyreq+36) is arithmetically fixed.

Sibling finding discovered (needs a new DF-ID) — worse than DF-2296

fwdev.c:561 copies to (void *)&xfer->send.payload — the address of the pointer field (DragonFly transcription bug; FreeBSD uses (void *)xfer->send.payload). Effects measured on the stock binary: 1. For any block FW_ASYREQ, 8..~72 bytes of struct fw_xfer after send.payload are overwritten with packet bytes (rig published offsets: send.payload=+80, recv.hdr=+96, recv.payload=+112, recv.pay_len=+120, mbuf=+128, malloc=+144; sizeof=152), and for pay_len>72 the copy overruns the 160-class fw_xfer allocation with attacker-controlled bytes — up to ~63KB (u16 req.len). 2. The smashed send.payload/recv.payload are then kfree()d by fw_xfer_free_buf (fwdev.c:586): captured stock panics include Fatal trap 9: general protection fault in _kfree ← fw_xfer_free_buf ← fw_ioctl (twice) and Fatal trap 12 in pmap_kvtom ← fw_xfer_free_buf (smash_panic_gfp_kfree.txt, dmesg_phaseA_gate.txt). 3. Behavioral control proven: planting recv.hdr tcode=2 in data[] steered the response path to the early-out; tcode=1 + recv.pay_len steered it into the response-copy branch; planting lenval steered the MAXREC gate. This is a local, operator-group kernel heap overwrite with fully controlled content and length — privesc-class. Recommended one-line fix: s/(void *)&xfer->send.payload/(void *)xfer->send.payload/ (NULL- or alloc-guard the payload pointer as appropriate).

Threat model / reachability (honest)

• Trigger: operator-group user, one ioctl (FW_ASYREQ, block tcode).
• Disclosure sink on stock fwohci: the over-read bytes are copied into xfer->send.payload; when pay_len <= MAXREC(fc->maxrec) they are transmitted to the FireWire peer (wire disclosure, up to 2048 bytes of adjacent heap per request on S800 hardware, maxrec 11). On S400 (typical, maxrec 10 → 2048 == data capacity) the gate rejects before transmission — but AFTER the bcopy; the over-read data then sits in the payload buffer until freed (no local read-back path exists via this ioctl on stock). Local user cannot read the over-read bytes directly; the sibling &payload bug (above) turns the same ioctl into a local heap overwrite instead.
• Privesc assessment: DF-2296 itself = remote-peer disclosure (leak); no local escalation. The sibling bug = local privesc-class heap overwrite, flagged.

Fix validation (A/B, fix.diff pay_len bound)

        if (pay_len > sizeof(asyreq->data)) {
            err = EINVAL;
            break;
        }

inserted after fwdev.c:530 (before fw_xfer_alloc_buf — no leak, no copy). Patched kernel (FWH #8): * malicious req.len=4096 → ioctl rc=-1 errno=22, NO wire transmit (hw.fwh_txcount unchanged by the malicious request); * legit req.len=2064 (pay_len 2048 == data[] capacity) → rc=0, full path, AT-START: 'wire' payload snapshot 2048 bytes — identical to the baseline-kernel behavior of the same request (run.legit_baseline.log, fix_run.log); * guest alive after both.

Artifacts

run_2296.log (phases + dmesg), dmesg_phaseA_gate.txt, dmesg_serial_run.txt, smash_panic_gfp_kfree.txt, spraydump.*.txt, run.legit_baseline.log, fix_run.log, poc_2296.c, fwharness.c/fwhctl.c (rig), env.txt.

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.