# DF-4092 — Unvalidated IOC-pg8 MaxNumPhysicalMappedIDs as num_slots: heap OOB write in mpr _mapping_process_dpm_pg0 (mpr twin of DF-4085)

**File:** `sys/dev/raid/mpr/mpr_mapping.c` (:2216, :2284-2290, :2327-2347, kmalloc :2140-2141, facts :2564-2565)

## Build

```
cc -O2 -Wall -o harness_df4092 harness_df4092.c
```
(DragonFly base cc 8.3; any unprivileged user; runs entirely in userland)

## Run

```
./harness_df4092
```

## Expected output (decisive lines)

```
  sizeof(dev_mapping_table) : 32 (expect 32 on amd64)
  max_devices               : 510 (kmalloc 16320 bytes, :2140)
  MaxNumPhysicalMappedIDs   : 0xffff (IOC pg8, unvalidated)
  DPM entry 0               : dev_idx=256 (in bounds!), num_slots=65535
  scenario A (cold garbage)  : wrote 254 entries [256,510), conflict gate: TRIPPED at first OOB block (goto fail :2336)
  scenario B (0xFFFF groom)  : wrote 4350 entries, 4096 of them PAST the table
  scenario C (all 0xFFFF)    : 65281 entries past table = 2088992 bytes linear smash
RESULT: OOB WRITE PRIMITIVE PROVEN (canary smash at stride 32; per-entry dpm_entry_num==BAD_IDX gate modeled verbatim)
```

Exit code 0 = primitive proven. `run.log` / `run.2.log` hold two identical
guest runs.

## What this proves

Object-level proof of the boot-time heap overflow primitive in
`_mapping_process_dpm_pg0`: with a fully **in-bounds** DPM `DeviceIndex`,
`num_slots = MaxNumPhysicalMappedIDs` (firmware u16, never validated) drives
the reservation loop past the `kmalloc(max_devices*32)` mapping table. The
harness models the loop **verbatim**, including the per-entry
`dpm_entry_num != MPR_DPM_BAD_IDX` conflict gate (`goto fail`) the mps
DF-4085 harness did not model: in-bounds entries always pass (cleared to
BAD_IDX by `_mapping_clear_map_entry`), the first OOB block is always read
OOB, and every consecutive OOB block holding `0xFFFF` at offset 16 is fully
overwritten with firmware-controlled data at 32-byte stride.

## Kernel-level status

Not reproducible on the audit guest: no SAS HBA on the PCI bus (env.txt), so
`mpr_attach` never runs. Same hardware gate as DF-4085 (mps) and
DF-3914/DF-3915 (mpr). Threat actor: malicious/buggy IOC firmware or a
PCI-passthrough/emulated HBA.