DF-1012 — VERDICT

Verdict

NOT REPRODUCED (live) — bug CONFIRMED via code trace, fix.diff compiles cleanly.

The heap-underflow bug claimed in the finding is real and the cited line numbers are exact, but it cannot be exercised on the audit guest because there is no USB UVC device (the QEMU/KVM guest's only USB is the ehci/xhci controllers with no devices attached) and therefore no code path that reaches uvc_drv_parse_data(). The bug is latent on this guest and live on any physical host into which a (potentially malicious) USB UVC webcam is plugged.

Mechanism (code trace)

uvc_drv_parse_data() parses a USB UVC Video Streaming interface's class-specific descriptors. The relevant lines:

• sys/bus/u4b/uvc/uvc_drv.c:1836 c fmt = data->fmt - 1; data->fmt is a heap allocation of data->nfmt struct uvc_data_format objects (96 bytes each on x86_64). Setting fmt = data->fmt - 1 deliberately points fmt one slot BEFORE the allocation, intending that the first VS_FORMAT_* descriptor will execute fmt++ to advance fmt onto slot 0.

• sys/bus/u4b/uvc/uvc_drv.c:1842-1846 c case UDESCSUB_VS_COLORFORMAT: cld = (struct uvc_vs_color_desc *)desc; fmt->colorspace = uvc_drv_get_colorspace(cld->bColorPris); break; colorspace is at byte offset 30 in struct uvc_data_format (verified from uvc_drv.h:629-643). So if a VS_COLORFORMAT descriptor appears in the descriptor list BEFORE any VS_FORMAT_* descriptor has executed fmt++, this writes data->fmt - 96 + 30 == data->fmt - 66 — a heap underflow 66 bytes before the data->fmt allocation.

• sys/bus/u4b/uvc/uvc_drv.c:1924 and :1955 c fmt->nfrm++; in the VS_FRAME_UNCOMPRESSED/VS_FRAME_MJPEG/VS_FRAME_FRAME_BASED cases. nfrm is at byte offset 8, so the same spec violation causes an 88-byte-underflow write.

uvc_drv_init_data_fmt() (which sizes data->fmt) counts descriptors without any ordering check, so a malicious webcam can present a descriptor list whose counts match but whose order violates the UVC spec (COLORFORMAT/FRAME before any FORMAT) and overflow the parser.

Why it does not reproduce on this guest

There is no userspace or hardware path that reaches the vulnerable function on the audit guest.

Exploit chain

none — not a memory-corruption primitive we can drive on this guest. The finding correctly identifies this as a heap underflow with attacker-controlled content (the bColorPris byte flows through uvc_drv_get_colorspace() into the underflow write) on a real host, which would corrupt adjacent slab objects. On a default-GENERIC host the slab INVARIANTS checks would likely catch the cross-type write and panic (DoS); on a noinv host a write-what-where primitive may be constructable by grooming the slab bucket holding data->fmt. Neither is exercisable here.

Fix

fix.diff adds a fmt_seen flag that is set after the first VS_FORMAT_* descriptor advances fmt, and guards the COLORFORMAT and both FRAME_* cases with if (!fmt_seen) break;. This is a minimal, targeted change at the root cause (unconditional writes to the intentionally-undersized fmt pointer) and matches the finding's recommended fix verbatim.

Fix validation

• fix.diff applies cleanly to /usr/src/sys/bus/u4b/uvc/uvc_drv.c with patch -p1 (5 hunks all succeeded).
• The patched uvc.ko module compiles cleanly with -Werror (see fix_build.log).
• Not live-tested (no USB UVC HW to attach a device to).

fix_status: not_testable (no live trigger available).

PoC changes

The finding folder was empty; this run authored: - poc.c — documentation harness explaining the trigger precondition and the vulnerable code path - fix.diff — the verified fix - build.sh, run.sh, build.log, run.log, env.txt, fix_build.log, manifest.json, VERDICT.md