# DF-5406 VERDICT — REPRODUCED (kernel heap OOB read/write via HID descriptor push/Pop level corruption; Fatal trap 12 inside hid_get_item)

## Bottom line

A malicious USB device's report descriptor drives the HID parser's item
stack level (`pushlevel`) out of range; on the next `hid_get_item()` call
the parser derives its working pointer **out of bounds** (`c =
&s->cur[s->pushlevel]`, usb_hid.c:248, `cur[MAXPUSH=4]` in a 1088-byte
`kmalloc` object) and then both **writes** device-supplied 32-bit values
and **reads back** 100-byte items through it. Reproduced three ways on the
QEMU guest against the production in-kernel functions (KLD harness calling
the kernel's own `hid_start_parse`/`hid_get_item` symbols):

1. deterministic cross-object write into a neighbouring live heap object at
   a pre-computed offset with pre-chosen content (guard scan),
2. controlled 32-bit write + read-back at **+24,436 bytes** past the object
   (`cur[255]`, single Pop byte),
3. **kernel panic**: `Fatal trap 12, supervisor write data, page not
   present, Stopped at hid_get_item+0x83: movq $0,0x58(%r10)` — the OOB
   zero-write of `c->loc.size` through `c = cur[255]` — after ~32 hammer
   rounds with filesystem churn. Guest wedged in DDB → `vm.sh status` = down.

## Root cause chain (path:line)

1. `sys/bus/u4b/usb_hid.c:88` — `uint8_t pushlevel` in `struct hid_data`
   (state is per-`hid_start_parse`, private, no locking needed — the bug is
   arithmetic, not races).
2. `:430-443 case 10 Push` — `s->pushlevel++` **unconditional**; only the
   copy to `s->cur[s->pushlevel]` is gated by `< MAXPUSH`. Four or more
   Push items leave `pushlevel ∈ [4..255]` while parsing continues and
   items are returned (`:278` top-block return, `:377` Collection,
   `:390` End collection).
3. `:444-461 case 11 Pop` — `s->pushlevel--` **unconditional**; one Pop at
   level 0 wraps 0 → **255** (uint8_t), the `else` branch merely prints.
   Parsing continues with the still-valid `c`, and the next Input item
   returns.
4. **Re-entry**: every caller loops `hid_get_item()` — `hid_locate`
   (:617), `hid_report_size` (:571), `hid_is_collection` (:751),
   `hid_is_mouse` (:869), and all HID drivers at attach (ukbd.c:1070+,
   ums.c:468+, uhid.c:784+, wsp.c:733, ucycom.c:243-245, uaudio.c:6110+).
   At `:248`, `c = &s->cur[pushlevel]` with pushlevel ∈ [4..255] → OOB.
5. Sinks through the OOB `c`:
   - `:289 hid_clear_local(c)` — 12 fields zeroed (48 bytes),
   - `:343/:369/:380 c->flags = dval`, `:345-346 c->loc.count/size`,
     `:402-405 logical_minimum/maximum = dval` (**arbitrary 32-bit**,
     4-byte items), `:399 _usage_page = dval<<16`, `:374 collevel++`,
     `:147 report_ID` via `hid_switch_rid`,
   - `:274/:376/:389 *h = *c` — **100-byte OOB read** into the caller's
     stack `hid_item`.
6. Threat: the report descriptor is fetched verbatim from the device
   (`usbd_req_get_hid_desc`, :801-843) and parsed at attach — a malicious
   USB device (or crafted device handed to the victim) controls every
   descriptor byte.

Primitive geometry (guest-verified, `mode 0`): `sizeof(struct hid_data) =
1088`, `offsetof(cur) = 24`, `sizeof(struct hid_item) = 100` → index k
writes at `s + 24 + 100k` (+4..+52 zeroed, +0/`_usage_page`, +4/+8
arbitrary dvals, …), k ∈ [4..255] chosen by Push/Pop bytes → **offsets
+424..+25524**, object ends at +1088. Same-zone neighbour chunks sit at
1152-byte stride (measured).

## Reproduction (baseline, unpatched kernel #0 Thu Jul 2 06:02:54)

- **Guard proof (deterministic cross-object corruption)**: harness
  `mode 3` — `hid_start_parse()` a zeroed 600-byte buffer (parser chunk
  now live and known), allocate same-size-class guards until one lands
  above it (measured delta 1152 = adjacent chunk), compute k so
  `cur[k].logical_minimum` (+24+100k+4) lands mid-guard, write the
  Push-spam trigger into the descriptor buffer the parser is anchored to
  (it has consumed nothing — exactly the device-attacker position), drive
  `hid_get_item()`:

  ```
  hidrig: live parser chunk s=0xfffff80089703200 (size 1088), 9 guards
  hidrig: target guard[7]=0xfffff80089703680 delta=1152 above s
  hidrig: target index k=16: marker 0xc0de0010 at s+1628 = guard[7]+476
  hidrig: firing 30-byte descriptor
  hidrig: parse done, 1 items returned
  hidrig: GUARD  7 base=0xfffff80089703680 +0x1dc: 0xc0de0010  <-- CROSS-OBJECT CORRUPTION
  ```

  The marker appears at the exact predicted guard offset (+0x1DC).
  (Earlier runs 0/24, 0/48: heap geometry — solved by allocating the
  target guard *after* the live parser chunk and rewriting the descriptor
  in place; no heap luck remains.)

- **Far write + read-back (`mode 1` phase A)**: descriptor `B4` (Pop @ 0)
  + item bytes; the second `hid_get_item()` call writes 0xFEED0001/0xFEED0002
  at `cur[255].logical_minimum/maximum` (s+25528/s+25532) and the trailing
  Input item copies them back: `item 2: logmin=0xfeed0001` — OOB write and
  OOB read round-trip at +24.4 KB.

- **Panic (hammer)**: 40 rounds of mode-1 (far write + free-list sweep +
  allocation churn) while two `find` walks generate kernel allocation
  traffic. Round ~32: `Fatal trap 12`, FVA 0xfffff80123ac008c,
  `supervisor write data, page not present`, `Stopped at
  hid_get_item+0x83: movq $0,0x58(%r10)` — the inlined
  `hid_clear_local()` zero store through `c = cur[255]` hitting an
  unmapped page. CPUs stopped, DDB, ssh dead, `vm.sh status` ⇒ down.
  (panic.txt, run.hammer.log.)

## Exploit-chain assessment

The primitive is a **relative kernel heap write**: chosen element index
(byte-offset 24+100k, k device-chosen ∈ [4..255]), chosen 32-bit content
(logical/physical min/max, unit, string_*, designator_* — full dval via
4-byte items; plus fixed zeroing of 12 fields and `_usage_page` dval<<16),
repeatable per parse pass, plus a 100-byte OOB read surfaced in driver
stack items. At real attach time the parser shares M_TEMP/~1-2KB size
classes with driver softc-adjacent allocations; overwriting a neighbour's
pointer/refcount/function-pointer field is the natural next step (the
guard run proves neighbour co-location at +1152 and exact-offset hits).
On this intentionally unhardened guest (no KASAN; no SMAP/SMEP/KASLR) the
remaining work is grooming victim objects at device-attach time —
mechanical for an attacker controlling the descriptor *and* the device
timing (multiple attach/detach cycles). Physical/USB vector, hence
High/CERT-metric 7.6 rather than Critical.

## Fix validation

`fix.diff`: reject Push when `pushlevel >= MAXPUSH-1`, reject Pop when
`pushlevel == 0` (nesting levels 1..3 preserved — all that ever worked).
Applied inside the guest `/usr/src`, `make -j6 nativekernel
KERNCONF=X86_64_GENERIC` (BUILD_RC=0), `make installkernel`, reboot into
kernel #1 Sun Oct 4 08:32:42 UTC 2026. Identical harness + workload:

- mode 3: same k=16 trigger → `guard scan done: 0/9 guards corrupted`
  (baseline: 1/9 at +0x1DC), parse completes;
- mode 1: churn completes, no trap;
- the full 40-round hammer + dual `find` churn: `round 1..40 done`,
  `HAMMER_ALL_DONE`, guest **up**, no trap, no dmesg anomalies.

Baseline behavior (guard corruption, panic) is GONE on the patched kernel.

## Attempts

7 trigger configurations (guard-placement strategy iterated 5×: batch
guards, LIFO-reuse, descending-magazine adaptation, live-parser+in-place
descriptor write — final: deterministic; then far-write, then hammer→panic).

## 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.