# DF-2262 — XPT_DEV_MATCH trusts user-supplied EDT cookie (cam_xpt.c)

## Verdict: REPRODUCED at root level (panic confirmed) — NOT an unprivileged escalation; fix.diff compiles.

**Classification:** `reproduced` (the source bug is real and **panics the kernel**
when triggered) / impact=**panic** (root→kernel DoS; the finding's own attacker model
is "root on host or root inside jail given /dev/xpt0") / the **unprivileged**
(`maxx`) path is **permission-gated** (`/dev/xpt0` is `0600 root:operator`,
`maxx` not in `operator`). The defense-in-depth `fix.diff` **compiles cleanly**
(`nativekernel rc=0`, `-Werror`, `-DINVARIANTS`).

### What was reproduced (root-level live confirmation)

The trigger harness `xpt_devmatch_poison.c` opens `/dev/xpt0` and issues
`CAMIOCOMMAND` with `func_code = XPT_DEV_MATCH`, `position_type = EDT|BUS`,
`generations[CAM_BUS_GENERATION] = 0` (bypassing the generation check), and
`cookie.bus = 0x4141414141414141`. The kernel traps immediately in `xptbustraverse`:

```
Fatal trap 9: general protection fault while in kernel mode
instruction pointer = 0x8:0xffffffff802acbf1
current process       = 996
Stopped at      xptbustraverse+0x61:    movq    0x10(%r15),%r13
```
(see `panic.txt`). The faulting instruction dereferences the fake `struct cam_eb *`
the kernel took verbatim from the user CCB.

Build (in-guest, root): `cc -I/usr/src/sys -o xpt_devmatch_poison xpt_devmatch_poison.c`
→ builds clean (9120-byte binary). Run as root panics the kernel (ssh dies,
`vm.sh status` ⇒ down); run as `maxx` fails with `Permission denied` on `/dev/xpt0`.

### The source bug (cited `path:line`)

`sys/bus/cam/cam_xpt.c`:
- `xptioctl` `CAMIOCOMMAND` accepts `XPT_DEV_MATCH` from userspace, maps the user
  buffers, and calls `xpt_action(inccb)` (`cam_xpt.c:1125-1179`).
- `xpt_action` `XPT_DEV_MATCH` (`:3262-3323`) picks the EDT path and calls
  `xptedtmatch(cdm)` (`:3307`).
- `xptedtmatch` (`:2427-2461`): the generation guard at `:2437-2439` is bypassable —
  it only fires when `generations[CAM_BUS_GENERATION] != 0` AND differs from
  `xsoftc.bus_generation`, so setting `generations[0] = 0` skips it entirely. Then,
  if `position_type & CAM_DEV_POS_BUS` and `cookie.bus != NULL` (`:2444-2445`), it
  passes the **raw user pointer** to `xptbustraverse((struct cam_eb *)cookie.bus, …)`
  (`:2446`) with no validation that it names a live `cam_eb`.
- `xptbustraverse` (`:2631+`) dereferences it: `TAILQ_NEXT(bus, links)`,
  `CAM_SIM_LOCK(bus->sim)` (`:2642`, `:2645`) → controlled deref → trap. This
  confirms finding claim (1): reliable kernel panic DoS.

The other two claims (info leak of kernel heap pointers via legitimate
`CAM_DEV_MATCH_MORE` returns; UAF via captured-valid-cookie + bus deregister) were
not separately exercised — claim (1) is sufficient to confirm the bug is live and
the trust-the-cookie defect is real.

### Why this is a root→kernel finding, NOT an unprivileged escalation

`/dev/xpt0` is `crw------- root operator` (mode 0600). `maxx` (uid 1001,
`groups=1001(maxx)`, not in `operator`) cannot open it:
```
$ id maxx                    -> uid=1001(maxx) ... groups=1001(maxx)
$ su -m maxx -c "camcontrol devlist"
camcontrol: couldn't open /dev/xpt0: Permission denied
```
The finding's own stated attacker is "root on host or root inside jail given
/dev/xpt0". Root→kernel is game-over by definition, so the **unprivileged-escalation
impact is `none` (gated)** while the **source bug is `reproduced` (panic)** and the
fix is warranted as defense-in-depth.

### Exploit chain

No unprivileged chain: the device is 0600 root-only, so `maxx` has no entry point.
The root-level panic is the demonstrated effect (claim 1 of the finding). A fuller
exploit (claims 2/3: KASLR-bypass info leak, UAF via bus-deregister) would also be
root-only and is not pursued — they add no unprivileged impact.

### Fix (defense-in-depth, VALIDATED — built, booted, re-tested)

`fix.diff` makes the generation check **mandatory** whenever `cookie.bus != NULL`:
a caller that wants to resume from a cookie must supply a current
`generations[CAM_BUS_GENERATION]`, closing the trivial
`generations[0]=0`-plus-arbitrary-cookie bypass. (Full hardening would additionally
re-validate that `cookie.bus` names a live `cam_eb`; the shipped fix closes the
trivial controlled-deref.) Validated in the combined `nativekernel` build
(`fix_build.log`).

**Phase 8 before/after (single-fix cam_xpt.c kernel, built + booted):**
- baseline `#0` (unpatched): `./xpt_devmatch_poison` → `Fatal trap 9 ... Stopped at
  xptbustraverse+0x61`, guest down (`panic.txt`).
- patched `#1`: `./xpt_devmatch_poison` → `ioctl returned 0, cdm.status=2`
  (`CAM_DEV_MATCH_LIST_CHANGED` — the fix's safe return), guest **stays up**
  (`fix_run.log`). The controlled-deref panic is gone.

### Reproduce (root only)

```
cc -I/usr/src/sys -o xpt_devmatch_poison xpt_devmatch_poison.c   # builds clean
./xpt_devmatch_poison                                            # as root -> panic
```
As `maxx`: `Permission denied` on `/dev/xpt0` (gate).