Firmware-image walks lack bounds: iwi_load_ucode odd-size size_t underflow (1-2 → SIZE_MAX) walks kernel memory past the image under IWI_LOCK until a page fault; iwi_load_firmware command-block walk reads up to 7 bytes past the DMA buffer and emits up to ~2^19 MMIO command blocks from unvalidated len (DF-3573/3591/3631 firmware-trust family)

DF-3841 — iwi(4) firmware-image walks lack bounds validation: (a) iwi_load_ucode() size_t underflow on odd ucode size -> unbounded kernel OOB read + permanent lock-held spin (if_iwi.c:2446-2447); (b) iwi_load_firmware() command-block walk: GETLE32 tail reads up to 7 bytes past the DMA buffer and unvalidated block length drives up to ~2^19 MMIO command-block writes under IWI_LOCK (if_iwi.c:2506-2527). Firmware-trust family: DF-3573 / DF-3591 / DF-3631.

WHAT TO LOOK AT mkbadfw.c userspace generator for a combined (v3) image with usize=9 (odd) — runs anywhere, output blob is the trigger artifact. fix.diff even-size rejection + walk bounds checks. run.log generator executed on the audit guest (RUN_OK).

BUILD cc -O2 -o mkbadfw mkbadfw.c RUN ./mkbadfw iwi_bss_bad EXPECT On hardware with the iwi driver: installing the blob as the iwi_bss firmware (root: fwget/kldload path) and bringing the interface up -> iwi_init_locked -> iwi_load_ucode walks off the image: size becomes SIZE_MAX -> kernel spins reading memory past the firmware buffer until it faults -> panic/hang.

SCOPE NOTE: installing a crafted firmware image requires root, exactly the trust boundary of the DF-3573/3591/3631 family findings (Low).

DF-3841 VERDICT — status: inconclusive (hardware-gated), source-level: CERTAIN

(a) iwi_load_ucode() (if_iwi.c:2404-2473): 2408-2409 const char uc = fw->data; size_t size = fw->size; 2446-2447 for (w = (const uint16_t )uc; size > 0; w++, size -= 2) MEM_WRITE_2(sc, 0x200010, htole16(w)); size comes, unvalidated, from the image: pre-3.0 images : fw->size = fp->datasize - sizeof(struct iwi_firmware_ohdr) (if_iwi.c:2228) — any parity; 3.0+ images : fw_uc.size = le32toh(hdr->usize) (if_iwi.c:2362) — any u32 (the :2352 size check is computed in size_t and so is NOT overflowable; parity is still free). With odd size the final iteration has size == 1: w reads 2 bytes at uc+size-1 — one byte past the image — and size -= 2 wraps size_t to SIZE_MAX. The loop then walks the kernel address space after the firmware buffer, word by word, MMIO-writing each value, holding IWI_LOCK inside iwi_init, until it hits an unmapped page -> kernel page-fault panic (or an effectively permanent spin if it maps through). Same pattern as DF-3631 (iwm_read_firmware TLV len -= roundup2 underflow).

(b) iwi_load_firmware() (if_iwi.c:2478-2527): 2501-2506 src = sc->fw_physaddr; p = sc->fw_virtaddr; end = p + fw->size; while (p < end) { dst = GETLE32(p); p += 4; src += 4; len = GETLE32(p); p += 4; src += 4; p += len; - No check that 8 header bytes remain: with < 8 bytes left, GETLE32 reads up to 7 bytes past end — past the fw DMA allocation when this image is the largest of the three (fw_dma_size == fw->size, if_iwi.c:3139-3141) — heap OOB read whose value is programmed into NIC command blocks. - len is unvalidated: len = 0xffffffff makes the inner while emit len/IWI_CB_MAXDATALEN (~524k) command blocks × 4 MMIO writes under the lock — a multi-second soft hang from a single image byte pattern.

Why not reproduced: guest has no iwi NIC (run.log) and loading replacement firmware requires root, which is the family's accepted threat model (DF-3573/3591/3631 all filed Low/certain on the same trust boundary). The generator ran successfully on the guest and produced the malformed blob (run.log: "wrote /tmp/iwi_bss_bad: version=300 bsize=16 usize=9 (odd!) fsize=256"). The underflow itself is plain arithmetic: (size_t)1 - 2 == SIZE_MAX.

Severity: Low (root-gated trigger, deterministic panic/hang once triggered).

Fix: fix.diff — reject odd ucode sizes; require 8 remaining bytes for a command-block header and len <= remaining data. Fix validation: not possible on this guest — fix_status not_applicable.

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.