DF-5664 — usb_alloc_mbufs() 32-bit alloc_size truncation (latent heap overflow)

WHAT sys/bus/u4b/usb_mbuf.c:69 assigns a 64-bit size_t product to usb_size_t alloc_size (uint32_t, sys/bus/u4b/usb_dragonfly.h:92), truncating it. kmalloc() then backs only the truncated byte count while the population loop lays out nblocks headers + data areas at the FULL stride — every data pointer past the truncation boundary points outside the allocation.

REACHABILITY (important) Privileged KLD harness only. Every in-tree caller is capped far below 2^32 (ugen bulk <=256KiB x2 blocks; ugen ISO <=49152 x1920 ~ 94MB; USB_FS_INIT 1x127; all drivers fixed constants or <= usbd_xfer_max_len). No unprivileged path reaches a truncating product TODAY. This is a latent CWE-190 -> CWE-787 defended for future callers.

BUILD (on host, from this directory) ./build.sh # pushes usbmbuf_of.c + Makefile into guest, builds KLD # in /root/df5664 (needs: touch opt_usb.h — automatic)

RUN ./run.sh # kldload ./usbmbuf_of.ko (BASELINE: panics guest) # after applying fix.diff and rebuilding the kernel (see VERDICT.md): dfbsd-qemu/vm.sh run_root 'cd /root/df5664 && kldload ./usbmbuf_of.ko' # PATCHED: "allocation FAILED (NULL)", guest stays up

EXPECTED (baseline, unpatched kernel) usbmbuf_of: sizeof(struct usb_mbuf)=48 usbmbuf_of: block_size=0x08000000 nblocks=32 usbmbuf_of: bytes truly required = 0x100000600 (4294968832) usbmbuf_of: kmalloc size (truncated!) = 0x600 (1536) <-- BUG usbmbuf_of: m[0..31] ... <== OOB (past allocation) <-- 32 wild ptrs Fatal trap 12: page fault while in kernel mode fault code = supervisor write data, page not present Stopped at usbmbuf_of_modevent+0x1cb: movb $0x41,(%rax) <-- proof

EXPECTED (patched kernel, fix.diff applied) usbmbuf_of: bytes truly required = 0x100000600 (4294968832) usbmbuf_of: allocation FAILED (NULL) <-- rejected guest stays up (kldload rc=0, uptime clean)

ARTIFACTS usbmbuf_of.c KLD harness (source of truth) Makefile guest-side kmod makefile build.sh / run.sh exact commands build.log full compiler output (clean, -Werror) run.log run transcript (baseline; ssh died on panic) panic.txt serial console: truncation math + Fatal trap 12 run.fixed.log patched-kernel run (guest survives) run.fixed.console.txt patched-kernel console excerpt env.txt guest/kernel details fix.diff 3-line guard, git-apply clean against sys/

DF-5664 VERDICT — usb_alloc_mbufs() 32-bit alloc_size truncation

Status: REPRODUCED (privileged KLD harness) — latent, no unprivileged in-tree path

The bug

sys/bus/u4b/usb_mbuf.c:62 declares usb_size_t alloc_size (uint32_t per sys/bus/u4b/usb_dragonfly.h:92). Line 69:

alloc_size = (block_size + sizeof(struct usb_mbuf)) * nblocks;

block_size is usb_size_t (u32), sizeof() is size_t (u64 on LP64), and nblocks is uint16_t — usual arithmetic conversions evaluate the RHS in 64-bit, and the assignment then truncates to 32 bits. kmalloc() (usb_mbuf.c:71) receives only the truncated count, while the population loop (usb_mbuf.c:77-91) lays out nblocks headers followed by data areas at the full, untruncated stride:

data_ptr = (void *)(m_ptr + nblocks);      /* headers first            */
...
data_ptr += block_size;                    /* full stride per block    */

Any product ≥ 2^32 therefore yields an undersized allocation whose data pointers (and, for larger nblocks, even the header array) reach past its end. Because block_size is always 8-aligned and sizeof(struct usb_mbuf) is 48 (multiple of 8), a caller can choose nblocks = 2^32 / block_size exactly, making the truncated size land precisely at nblocks*48 — headers fit, and the first data pointer sits at exactly one-past-the-end of the chunk (quiet adjacent-slab corruption), with later data pointers up to nblocks * block_size bytes beyond (wild writes). Full attacker control of both factors is required; today only in-kernel drivers call this API.

Reachability analysis (why this is Low/hardening, not High)

The only in-tree caller is usb_fifo_alloc_buffer() (usb_dev.c:1984, called from usb_dev.c:1993). All its call sites and their ceilings:

Largest in-tree product ≈ 94 MB — two orders of magnitude below 2^32. No unprivileged user can reach a truncating product today. The primitive is real and armed for any future caller that scales either factor; the fix is a 3-line guard.

Reproduction (guest: DragonFly 6.5-DEVELOPMENT, X86_64_GENERIC)

KLD harness usbmbuf_of.c (in pack) calls the real in-kernel usb_alloc_mbufs (symbol at ffffffff80a4f250, compiled into GENERIC) with block_size=0x08000000, nblocks=0x20:

• true requirement: (0x08000000 + 48) * 32 = 0x100000600 (4,294,968,832)
• truncated allocation: 0x600 = 1536 bytes (console printout, panic.txt)
• all 32 mbufs enqueued; m[0]->cur_data_ptr == base + 0x600 — exactly one-past-end of a 1536-byte chunk (adjacent-object corruption)
• m[31]->cur_data_ptr == base + 0xF8000600 (~3.7 GiB past the chunk)
• one-byte write through m[31]->cur_data_ptr:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xfffff8020ebade80
fault code            = supervisor write data, page not present
Stopped at usbmbuf_of_modevent+0x1cb: movb $0x41,(%rax)

Guest died in DDB (ssh dropped, vm.sh status = down). Full serial-console transcript in panic.txt. This is proof the primitive exists; it is NOT an unprivileged exploit — loading the harness requires root.

Fix validation

• fix.diff: compute in size_t, reject > 0xFFFFFFFFU (return NULL). git apply --check clean against sys/bus/u4b/usb_mbuf.c.
• vm.sh reset with-src → patched guest /usr/src → make nativekernel → make installkernel → reboot (kernel #1, Oct 9 2026).
• Re-ran the exact harness: console shows bytes truly required = 0x100000600 then allocation FAILED (NULL) — no kmalloc, no queue population, kldload rc=0, guest stayed up (run.fixed.log / run.fixed.console.txt). Baseline panic is GONE.

What I checked and found CLEAN (negative results with weight)

• Layout math (usb_mbuf.c:77-91): perfect fit, last data byte == end of allocation; no off-by-one; 48-byte header keeps data 8-aligned on x86_64.
• Alignment wrap (usb_mbuf.c:65): block_size in [0xFFFFFFF9..0xFFFFFFFF] wraps to 0 → if (nblocks && block_size) skips → caller sees ENOMEM via usb_dev.c:1996. Benign, no bypass (FreeBSD-identical code).
• M_WAITOK + NULL check (usb_mbuf.c:71-75): dead-but-harmless defensive code.
• Queue macros (usb_mbuf.h:46-84 ENQUEUE/DEQUEUE/PREPEND/QFULL/POLL): correct singly-linked discipline, empty-queue tail handling verified.
• Consumer copies (usb_dev.c:2064-2137, 2175-2214): all MIN(len, cur_data_len)-bounded under f->priv_lock.
• M_ZERO on allocation → no uninitialized-kernel-memory leak path.
• Consumer race hazard (NOT this file): ugen_transfer_setup (usb_generic.c:145-167) drops priv_lock around usbd_transfer_setup + usb_fifo_alloc_buffer — a second read()/write() on the same ugen fifo can interleave (f->xfer still NULL) and kfree queue_data mid-population. Same family as existing DF-5309/DF-5314/DF-5315 (usb_dev/usb_generic); root cause lives there, not in usb_mbuf.c.
• usb_ethernet.c (DF-5493..5495 this pass) does NOT touch this file (zero references to usb_mbuf/USB_IF_*/usb_alloc_mbufs).

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.