# DF-4240 — VERDICT

**REPRODUCED** (kernel memory corruption, crash; fix validated on a rebuilt kernel).

## What was proven, and how

`sys/dev/raid/dpt/dpt_scsi.c` is compiled into the guest's X86_64_GENERIC kernel
(`nm /boot/kernel/kernel` → `dpt_attach` @ 0xffffffff80439500, `dpt_init` @ …89f0+,
`dptallocccbs` @ …75e0, `dpt_action` @ …8010). There is no DPT HBA on the guest, so the
rig (`dfdpt_rig.c`) stands in for the hardware only:

1. **Baseline, controlled** (`chan8 4`, `run.log` + `run_chan4_controlled.log`):
   fabricate a post-`dpt_init` softc (real bus_dma, real DMA-mapped dccb array, free list
   built by production `dptallocccbs`), set `channels = 4` — exactly what production
   `dpt_init` computes from a device-fed `MAX_CHAN = 3` (dpt_scsi.c:1313, no clamp) — and
   call the **production `dpt_attach`**. Observed:
   - `attach_ret=4`: the loop ran iteration i=3 out of bounds;
   - `&sims[3] == &paths[0]` (rig prints 0 bytes apart): iteration 3 stored a `cam_sim*`
     into `paths[0]`, clobbering the path pointer installed by iteration 0 —
     `paths[0] == sims[3]` value confirmed ("type confusion: YES");
   - canary `commands_processed` 0x41414141 → 0x8d481e20 and `lost_interrupts`
     0x42424242 → 0xfffff800: together the kernel pointer 0xfffff8008d481e20 that
     `xpt_create_path(&dpt->paths[3])` wrote across both counters (8-byte store at
     `&paths[3] == &commands_processed`).
2. **Baseline, catastrophic** (`chan8 8`, `run_channels8_fault.log`): with channels=8 all
   ten OOB stores execute; the store at `&sims[7]` (== `&channels`+`max_id`) corrupts the
   loop-bound field `channels` with the low 32 bits of a kernel pointer, the loop runs
   away, and production `xpt_create_path` faults writing a `cam_path*` to an unmapped
   page 77,824 bytes past the softc:
   `Fatal trap 12: page fault … supervisor write data, page not present …
   xpt_create_path+0x6b: movq %rbx,(%r12)` — system down in DDB.
3. **Fix validation** (`fix_validation.log`): all three dpt fixes applied to the guest's
   /usr/src, kernel rebuilt (nativekernel, gcc 8.3) and booted. The rig's `fullinit`
   path emulates the EATA config handshake (virtual HBA kthread: watches HA_WCOMMAND,
   DMA-feeds the 0xc1 config page incl. `MAX_CHAN=7`, raises HA_AIRQ; the handshake
   emulation is race-free — see rig comments) so the **production `dpt_init`** parses the
   device-fed config itself:
   - `dpt7: controller reported 8 channels; clamping to 3` (the fix)
   - `dpt7: FW Rev. , 3 channels, 16 CCBs` (production init banner — full success)
   - production `dpt_attach` returned 3; canaries `0x41414141→0x41414141`,
     `0x42424242→0x42424242` **intact**; slot at +176 still reads 0x4242424241414141
     (the canary pair) and +184 reads 0xf00000003 (`channels=3`, `max_id=15` — the
     softc's own fields, no pointer store); `runaway=0`.

   Baseline behavior gone on the patched kernel; normal 3-channel attach unaffected.

## Threat model

All inputs are device-fed: `conf.MAX_CHAN` arrives over the EATA PIO/DMA config protocol
from the PCI card (a hostile or glitching controller — firmware bug, power blip, PCI
reset — or a passed-through/virtualized device). Attach runs once per boot/hotplug, so
the corruption is single-shot but destructive: with MAX_CHAN=3..4 it type-confuses
`paths[0]` (CAM later treats a `cam_sim*` as a `cam_path*`) and turns two counters into a
pointer; with MAX_CHAN≥5 it corrupts `channels`/`max_id`, the TAILQ linkage of
`dpt_softcs`, and — via the loop-bound feedback — writes an unbounded stream of kernel
pointers past the softc (demonstrated page fault). Local unpriv→root is not the threat
model here; this is a hostile/failed-device kernel-corruption bug.

## Notes / caveats

- The rig's `path0_holds_sim` detector compares the value at `&sims[3]` with the value at
  `&paths[0]` — the *same address* — so it prints "YES" even on the patched kernel where
  no OOB store happened (`&paths[0]` legitimately holds its own path). The canaries and
  `attach_ret`/`channels` are the real discriminators; VERDICT relies on those.
- The chan8 baseline bypasses `dpt_init` (fabricates its output), because the full
  handshake emulation was built for the fix-validation run; the `fullinit` path closes
  that gap end-to-end on the patched kernel (device → MAX_CHAN → clamp).
- Earlier seed evidence (`dpt_df4240_layout.c`, old `run.log`) was a userland ABI layout
  proof only; superseded by this run.

Bottom line: the unclamped, controller-fed channel count drives production `dpt_attach`
into demonstrated out-of-bounds pointer stores (type confusion over live softc members
and an uncontrolled runaway write), and the one-line clamp in `fix.diff` removes it.

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