# DF-1298 — update_slot_layout_info heap overflow (amdgpu display VBIOS parser)

## Verdict
**NOT TESTABLE AT RUNTIME on this guest — confirmed real latent vulnerability in source.**

## Mechanism (confirmed by source trace)
`sys/dev/drm/amd/display/dc/bios/bios_parser.c:2601` `update_slot_layout_info()`
parses an `ATOM_BRACKET_LAYOUT_RECORD` from the GPU's VBIOS image.

- Line 2634: the guard `sizeof(ATOM_BRACKET_LAYOUT_RECORD) <= record_header->ucRecordSize`
  only proves the base struct (one flex element) is readable — it says nothing
  about the connector count.
- Line 2654: `slot_layout_info->num_of_connectors = record->ucConnNum;`  (`ucConnNum`
  is a raw `u8` from VBIOS, range 0–255, no bounds check).
- Line 2655: `for (j = 0; j < slot_layout_info->num_of_connectors; ++j)` writes
  `slot_layout_info->connectors[j]` each iteration.
- `connectors` is a fixed array of `MAX_CONNECTOR_NUMBER_PER_SLOT` = **16**
  (`sys/dev/drm/amd/display/include/grph_object_defs.h:172`).  `slot_layout_info`
  is `&board_layout_info->slots[i]` (line 2777), an embedded struct, so an
  overflow writes past the slot into adjacent `slots[]` / whatever follows the
  `board_layout_info` allocation → **heap overflow**.  The overflow bytes
  (`connector_type`, `length`, `position`, `connector_id`) are all
  attacker-shaped (taken from the VBIOS record), so content is controllable.

## Why it does not reproduce on this guest
- amdgpu is **not** in `X86_64_GENERIC`; it exists only as the loadable module
  `amdgpu.ko`, which is **not loaded** (`kldstat`).
- The only VGA device is `vgapci0` = QEMU/Bochs std-VGA (`1234:1111`), **not an
  AMD GPU**.  amdgpu never attaches, so the VBIOS parser never runs.
- The parsed data is the GPU card's own VBIOS ROM — there is no userspace
  syscall that feeds this parser on a GPU-less machine.  (Case d: genuinely not
  reachable on this kernel/guest.)

## Severity / realistic ceiling
On a host with an AMD GPU whose VBIOS contains (or has been maliciously
reflashed to contain) `ucConnNum > 16`, this is a kernel heap overflow in the
display init path.  Realistic impact: panic / heap corruption at GPU/driver
bring-up; the data comes from firmware, so the practical attack vector is a
malicious or buggy VBIOS rather than a pure unprivileged syscall.  Still a
real memory-safety defect worth fixing.

## Fix (see fix.diff)
Clamp `num_of_connectors` to `MAX_CONNECTOR_NUMBER_PER_SLOT` before the loop.
This is a compile-validated one-line guard (module build of amdgpu / or kernel
module compile).  Runtime cannot be exercised on the GPU-less guest.

## Note
The job brief's "DF-1298: mpr SAS" label was wrong — `bios_parser.c` is the
amdgpu display BIOS parser, not the `mpr` SCSI driver.  Verified against the DB
(`file = sys/dev/drm/amd/display/dc/bios/bios_parser.c`).