# DF-1783 — radeon_bios.c heap overflow in radeon_atrm_call

## Verdict
**REPRODUCED (logic/harness)** — bug confirmed by source trace. Not
live-triggerable on the default QEMU guest: requires a malicious ACPI
_ATRM method (custom SSDT / PCI option ROM / malicious platform
firmware). The QEMU default ACPI exposes no _ATRM.

## Mechanism (path:line)
* `sys/dev/drm/radeon/radeon_bios.c:269` — `rdev->bios = kmalloc(size=256*1024, ...);`
* `sys/dev/drm/radeon/radeon_bios.c:275-283` — caller loop `i=0..63`,
  `offset = i*4096`, `len = 4096`; only checks `if (ret < ATRM_BIOS_PAGE) break;`
  — no upper bound on the returned length.
* `sys/dev/drm/radeon/radeon_bios.c:207` — `memcpy(bios+offset, obj->Buffer.Pointer, obj->Buffer.Length);`
  — uses **ACPI-returned** `Length`, not the caller's `len` argument.
* No `obj->Type == ACPI_TYPE_BUFFER` check; `ACPI_OBJECT` is a union, so
  a non-Buffer return aliases `Buffer.Length` / `Buffer.Pointer` with
  other union fields → wild pointer / wild length.

At `i = 63`, `offset = 258048`; the 256 KB `rdev->bios` has 4096 bytes
left. An ACPI response with `Length > 4096` overflows by
`(Length - 4096)` bytes into adjacent heap.

## Phase 6 escalation
Trigger is malicious platform firmware. Attacker controls both the
overflow size and the source bytes. Full attacker-shaped heap
corruption of the slab that holds `rdev->bios` → victim-object overwrite
→ uid0 on this guest. Not developed because the default guest has no
radeon GPU and no _ATRM.

## PoC
`harness.c` simulates the caller loop with the malicious response
(`ACPI len = 8192` at `i=63`). Shows the 4096-byte overflow past the
256 KB `rdev->bios` end.

## Fix
`fix.diff` adds a `Type == ACPI_TYPE_BUFFER` check and clamps the
memcpy length to the caller's `len`. Validated by a clean `radeon.ko`
rebuild with the patch applied.