DF-2351 — uint16→uint8 truncation of nfmt → NULL-deref panic at device attach

sys/bus/u4b/uvc/uvc_drv.c — uvc_drv_init_data_fmt() counts formats/frames/ intervals into uint16_t locals (uvc_drv.c:1674) but stores them into the uint8_t fields data->nfmt/nfrm/nitv (uvc_drv.h:662-665, store at uvc_drv.c:1737-1739). With exactly 256 VS_FORMAT_* descriptors the allocation is sized with the full count (correct, 24 KB) but data->nfmt == 0. The later default-format search in uvc_drv_init_cur_fmt_frm() (for (i = v->data->nfmt; i > 0; i--), uvc_drv.c:1457) never runs, fmt stays NULL, and fmt->nfrm (uvc_drv.c:1463) dereferences NULL.

Threat: a malicious USB webcam whose configuration descriptor contains 256 format descriptors — deterministic kernel panic at attach, no user interaction beyond plugging (or USB passthrough) in.

Evidence class

Production-handler KLD dispatch rig: the four unmodified production uvc driver sources are #included into uvc_rig.ko (see rig/uvc_rig.c), so the descriptor parsing exercised below is the exact in-tree code. The rig synthesizes only the USB transport (a fake struct usb_device whose ->cdesc is the crafted config descriptor a malicious webcam reports and whose ->ifaces[1].idesc points at the VideoStreaming interface descriptor) — no emulated UVC webcam exists for this QEMU guest.

Build / run

./build.sh                       # push rig + triggers to guest, build uvc_rig.ko (gcc 8.3, -Werror)
./run.sh                         # reset guest, load rig, sysctl hw.usb.uvcrig=2351

Expected output (decisive lines, see panic.txt)

RIG2351: production uvc_drv_init_data_fmt ret=0
RIG2351: counted nfmt=256 (uint16_t local) -> stored data->nfmt=0 nfrm=0 nitv=0 fmt=0xfffff80118496000  <-- TRUNCATION
RIG2351: production uvc_drv_parse_data ret=0 (data->nfmt=0)
RIG2351: entering production uvc_drv_init_cur_fmt_frm ...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
Stopped at      uvc_drv_init_cur_fmt_frm.cold.36:       movq    0x8,%rax

fault virtual address = 0x8 is exactly offsetof(struct uvc_data_format, nfrm) from a NULL fmt.

Fix validation

fix.diff widens nfmt/nfrm/nitv to uint16_t and adds NULL-fmt guards in uvc_drv_init_cur_fmt_frm() and the uvc_drv_init_video() GET_CUR fallback. Re-running the identical trigger on the patched rig (fix_run.log):

RIG2351: ... stored data->nfmt=256 ... fmt=0xfffff80118660000
No frame desc found for default format.
RIG2351: init_cur_fmt_frm returned 22 -- NO PANIC

DF-2351 — VERDICT: REPRODUCED (panic, deterministic) — FIX VALIDATED

Bottom line

The claimed truncation and the claimed NULL-deref panic are both real and were demonstrated inside the kernel with the production uvc code paths:

1. uvc_drv_init_data_fmt() (production, unmodified, compiled into uvc_rig.ko from /usr/src/sys/bus/u4b/uvc/uvc_drv.c) counted nfmt = 256 (uint16_t local) and stored data->nfmt = 0 (uint8_t field) while allocating the correctly sized 24 KB buffer (fmt=0xfffff80118496000) — the console line proves the truncation exactly as the finding describes (uvc_drv.c:1674 vs 1737).
2. uvc_drv_parse_data() (production) then completed with data->nfmt == 0, exactly as at attach time.
3. uvc_drv_init_cur_fmt_frm() (production, uvc_drv.c:1457-1463) skipped the for (i = v->data->nfmt; i > 0; i--) search, left fmt == NULL, and faulted reading fmt->nfrm:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8                      <- offsetof(uvc_data_format, nfrm)
Stopped at uvc_drv_init_cur_fmt_frm.cold.36: movq 0x8,%rax

(uvc_drv.c:1463). The guest panicked; ssh died; vm.sh status = down.

Line-by-line trace (all cited in sys/bus/u4b/uvc/)

• uvc_drv.h:662-665 — uint8_t nfmt, nfrm, nitv (the truncating store target)
• uvc_drv.c:1674 — uint16_t nfmt, nfrm, nitv (counters)
• uvc_drv.c:1690-1698 — nfmt++ per VS_FORMAT_* descriptor
• uvc_drv.c:1726-1731 — allocation uses the full uint16 values (correct size)
• uvc_drv.c:1737-1739 — data->nfmt = nfmt truncation store
• uvc_drv.c:1457-1462 — search loop skipped when nfmt == 0
• uvc_drv.c:1463 — if (fmt->nfrm == 0) NULL dereference (panic site)
• same pattern (unfixed) in the GET_CUR fallback at uvc_drv.c:1528-1535

Production reachability

uvc_drv_attach (uvc_drv.c:2673) → uvc_drv_parse_ctrl (2140) → uvc_drv_parse_data (1776) → uvc_drv_init_data_fmt (1667); then uvc_drv_init_video (1488) reaches uvc_drv_init_cur_fmt_frm (1580) as soon as the device answers GET_DEF or GET_CUR probe control requests — which a malicious device does by definition. Config-descriptor budget: 256 × 11-byte VS_FORMAT_MJPEG = 2816 bytes (+ headers = 2869 total), far inside the 65535-byte wTotalLength limit. No privilege, no user interaction: the trigger is device attach.

What the rig replaces (and why)

The QEMU guest has no emulated UVC webcam (QEMU ships no such device), so the rig fabricates struct usb_device (->cdesc, ->ifaces, ->ifaces_max) and calls the production parse/attach functions with it. Everything from descriptor walk to the panic is in-tree code. The two usbd_* helpers used (usbd_find_descriptor, usb_desc_foreach) only read udev->cdesc/udev->ifaces — both attacker-controlled at attach time in production.

Fix validation (same rig, patched production sources)

After applying fix.diff (uint16_t fields + NULL guards), the identical trigger prints stored data->nfmt=256 and returns EINVAL from uvc_drv_init_cur_fmt_frm — no panic (see fix_run.log). Baseline panic vs patched clean return, same binary rig, same crafted descriptors.

Impact

Deterministic kernel NULL-deref panic (local DoS) at USB device attach; requires attacker-controlled USB hardware (or USB passthrough of a crafted device). No memory-disclosure or control-flow effect: fmt is NULL, the read is at address 0x8 — pure denial of service. Matches the finding's Medium severity.

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.