DF-5378 — Use-after-free of the UVC control graph in uvc_query_v4l2_ctrl()/uvc_query_v4l2_menu()

Where

• sys/bus/u4b/uvc/uvc_ctrls.c:1102-1119 — uvc_query_v4l2_ctrl() (reached from unprivileged ioctl(VIDIOC_QUERYCTRL) on the 0666 /dev/videoN)
• sys/bus/u4b/uvc/uvc_ctrls.c:1122-1157 — uvc_query_v4l2_menu() (VIDIOC_QUERYMENU)
• Victim sites: uvc_ctrls.c:1065 (write ctrl->info.cached_sub_info_idx = j), uvc_ctrls.c:1001 and :1150 (strlcpy of freed sub_info->v4l2_name into the user-visible struct), :1090 (walk of freed topo_nodes), :1107 (lockmgr on freed ctrl->mtx)
• Free site (no lock, no cdev drain first): uvc_drv.c:2507 → uvc_drv_destroy_ctrl() (uvc_drv.c:2453-2474) → uvc_ctrl_destroy_mappings() (uvc_ctrls.c:872-897) + uvc_free_topo_node() (uvc_drv.c:1992-2011); destroy_dev() only at uvc_drv.c:2511 — AFTER the free.

Attack model

/dev/videoN is created 0666 (uvc_v4l2.c:783-785). An unprivileged local user keeps it open and issues VIDIOC_QUERYCTRL/VIDIOC_QUERYMENU. The evil USB webcam (or a plain unplug) disconnects → uvc_drv_detach() frees the entire control graph while the ioctl is in flight (or before destroy_dev() drains it). The ioctl then writes 1 byte into a freed chunk and copies up to 31 bytes of reclaimed kernel heap out to userspace.

Build / run (as verified)

./build.sh                  # KLD harness that #includes the REAL uvc sources
./run.sh                    # mode 1 at kldload; mode 2 via sysctl

Expected (baseline)

mode 1 (controlled reclaim, guest stays up):

HARNESS DF-5378[baseline]: ret=0 name=<Tilt (Absolute)>
HARNESS DF-5378: production uvc_drv_destroy_ctrl() done - ... DANGLING
HARNESS DF-5378: all 11 freed chunks reclaimed at their original addresses
HARNESS DF-5378[UAF query]: ret=0 name_len=31   (q.name = 0x5A*31)
HARNESS DF-5378: *** UAF READ/LEAK CONFIRMED: 31 bytes ... ***
HARNESS DF-5378: *** UAF WRITE CONFIRMED: uvc_ctrls.c:1065 wrote
                  cached_sub_info_idx=1 ... (was 0xAA) ***
HARNESS DF-5378[UAF menu]: ret=0   (qm.name = 0x5B*31)  -> QUERYMENU too

mode 2 (wild, guest dies):

HARNESS DF-5378[wild]: ctrl chunk poisoned; expect fatal trap ...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x5a5a5a5a5a5a5aXX
-> db> prompt, vm.sh status down  (panic.txt)

After fix.diff (applied to guest /usr/src, harness rebuilt)

sysctl hw.uvcharness=3
HARNESS DF-5378[fix baseline]: ret=0 name=<Tilt (Absolute)>
HARNESS DF-5378[fix post-detach]: query ret=19 (ENODEV), guest up

Files

uvcharness.c   harness (real driver sources compiled in)
run.log        mode 1 output (controlled UAF proof)
panic.txt      mode 2 serial console (wild-pointer panic)
fix.log        post-fix output
leak_sample.txt raw leaked-name bytes

DF-5378 VERDICT

Status: reproduced (deterministic, production-code UAF with both a 1-byte controlled write into a freed kernel chunk and a 31-byte kernel-heap disclosure per query through the unprivileged VIDIOC_QUERYCTRL/VIDIOC_QUERYMENU handlers; plus an uncontrolled variant that panics the kernel). Impact: memcorrupt (UAF write + kheap leak; panic variant), confidence: certain.

Root cause (path:line)

• sys/bus/u4b/uvc/uvc_drv.c:2503-2511 — uvc_drv_detach() frees the whole control graph via uvc_drv_destroy_ctrl(sc->ctrl) at 2507 and only calls uvc_v4l2_unreg(sc->video) (→ destroy_dev(), uvc_v4l2.c:756-769) at 2511, after the free. uvc_drv_destroy_ctrl() (uvc_drv.c:2453-2474) walks the graph without taking c->mtx and frees sub_infos[], menus[], uvc_data, controls[], the uvc_topo_node list (uvc_free_topo_node, uvc_drv.c:1992-2011) and sc->ctrl itself (uvc_drv.c:2472).
• /dev/videoN is created 0666 (uvc_v4l2.c:783-785), so any local user can hold it open. A device disconnect (USB unplug — or an evil webcam whose firmware disconnects itself on demand) triggers that detach while a VIDIOC_QUERYCTRL/VIDIOC_QUERYMENU is in flight (or enters before destroy_dev() drains it).
• The in-flight ioctl then executes, on freed memory, inside the audited file:
• uvc_ctrls.c:1107 — UVC_LOCK(&video->ctrl->mtx) lockmgr on the freed uvc_drv_ctrl chunk;
• uvc_ctrls.c:1090 — STAILQ walk of freed topo_nodes;
• uvc_ctrls.c:1065 — ctrl->info.cached_sub_info_idx = j; a 1-byte write (value 0..4, attacker-influenced through the v4l2 id it searches) at a fixed offset of the freed struct uvc_control array chunk;
• uvc_ctrls.c:1001 / uvc_ctrls.c:1150 — strlcpy() of the freed sub_info->v4l2_name into the user-visible query->name/qm->name: 31 bytes of whatever now occupies the freed chunk are copied to userspace, repeatable at will.

Distinct from DF-2353 (that finding's victim is sc->data, freed at uvc_drv.c:2506 and consumed by the format/frame paths in uvc_drv.c); the victim here is sc->ctrl's control graph (freed at 2507), consumed by the two query handlers of uvc_ctrls.c, with different primitives (write + name disclosure).

Reproduction (KLD harness with production code, the DF-5305/5306 pattern)

The harness #includes the four real uvc driver sources, builds a real control graph with the real uvc_drv_init_ctrl() + uvc_drv_parse_ctrl() + uvc_ctrl_init_dev() from a crafted VideoControl-only descriptor blob (camera terminal with bits 1 and 11: AE_MODE + PANTILT_ABSOLUTE), runs the real uvc_query_v4l2_ctrl(), then executes the real uvc_drv_destroy_ctrl() and reclaims every freed chunk at its exact address (what a heap-grooming attacker does in the guaranteed race window).

mode 1 (controlled; guest stays up) — decisive lines from run.log:

HARNESS DF-5378[baseline]: ret=0 name=<Tilt (Absolute)>
HARNESS DF-5378: production uvc_drv_destroy_ctrl() done - ... DANGLING
HARNESS DF-5378: all 11 freed chunks reclaimed at their original addresses
HARNESS DF-5378[UAF query]: ret=0 name_len=31
  q.name = 5a 5a ... 5a 00      (31 marker bytes + NUL)
*** UAF READ/LEAK CONFIRMED: 31 bytes of attacker-marked FREED-chunk
    content copied into the user-visible queryctrl.name ***
*** UAF WRITE CONFIRMED: uvc_ctrls.c:1065 wrote cached_sub_info_idx=1
    into the freed-and-reclaimed controls[1] chunk (was 0xAA) ***
HARNESS DF-5378[UAF menu]: ret=0, qm.name = 5b*31
*** QUERYMENU disclosure confirmed (strlcpy from freed sub_info at
    uvc_ctrls.c:1150) ***

mode 2 (uncontrolled; guest dies) — panic.txt:

HARNESS DF-5378[wild]: ctrl chunk poisoned; expect fatal trap reading
    ~0x5a5a5a5a5a5a5a5a+112 (topo_node->controls_num) ...
Fatal trap 9: general protection fault while in kernel mode
Stopped at uvc_search_control.isra.3+0x20: movl 0x70(%rax),%ecx

i.e. the production walk dereferenced 0x5a5a5a5a5a5a5a5a + 0x70 — the
freed ctrl chunk's poisoned `topo_nodes.stqh_first`. `vm.sh status`:
down.

Exploitability

• The window is not a narrow race in practice: the ioctl handlers are reachable until destroy_dev() drains (uvc_drv.c:2511), i.e. for the whole duration of uvc_drv_destroy_ctrl() plus unbound-open-fd time; an unprivileged user loops QUERYCTRL while the evil device disconnects.
• Demonstrated primitives: (a) fully attacker-controlled fake graph after same-address zone reclaim (the walk follows attacker pointers), (b) 1-byte write (value 0..4) at a fixed offset of a freed ~184-byte M_UVC chunk, (c) 31 bytes of kernel heap disclosed per query, (d) lockmgr on freed memory (contention on attacker-crafted lock words → further state corruption).
• uid=0 was not completed: the standard audit guest has no UVC device, so the real /dev/videoN path cannot be driven end-to-end here; the harness proves the primitives deterministically. On hardware, grooming the M_UVC size-class zones from the same 0666 device (other /dev/videoN ioctls allocate M_UVC: e.g. open/REQBUFS paths, cdev priv) is the route to turning the fake-graph control into arbitrary-pointer walk → write.

Fix validation

fix.diff (applies with git apply -p0 from /usr/src): 1. uvc_drv_detach(): destroy the cdev first (uvc_v4l2_unreg() drains in-flight ioctls) and NULL video->ctrl under the ctrl lock before uvc_drv_destroy_data/destroy_ctrl; 2. uvc_query_v4l2_ctrl()/uvc_query_v4l2_menu() (uvc_ctrls.c): return ENODEV when video->ctrl == NULL; 3. uvc_drv_destroy_ctrl(): hold c->mtx during teardown + lockuninit().

Both patched files compile with -Werror in the harness build (fix_build.log). Rebuilt against the patched sources and re-run (fix.log):

HARNESS DF-5378[fix baseline]: ret=0 name=<Tilt (Absolute)>
HARNESS DF-5378[fix post-detach]: query ret=19 (ENODEV), NO freed-memory
access, guest up

i.e. with the fixed detach sequence (NULL-out under lock, then destroy), the production (patched) query handler refuses the dangling pointer instead of walking freed memory, and the live-graph path is unaffected. Full-kernel rebuild not run (harness pattern as in DF-5305/5306; the patch only touches the two driver files, both compile-checked).

Impact

Unprivileged local user + device disconnect ⇒ kernel use-after-free with write primitive and repeatable kernel-heap disclosure (High). Panic variant confirmed. Root-cause class matches the project's memcorrupt bucket.

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.