# DF-4967 — radeon_gart_bind/unbind take a 32-bit `offset`: GTT aperture offsets ≥ 4 GiB truncate and alias GART entries across buffer objects

**File:** `sys/dev/drm/radeon/radeon_gart.c:241,286`
**Class:** wrong-index aliasing → cross-process GPU memory redirection (not kernel OOB)
**Severity:** Medium (requires root-configured oversized GTT + radeon hardware)
**Status:** kernel-behavior UNTESTED on this guest (no ATI/AMD GPU present); code-path arithmetic
validated by `gart_math.c` run on the guest (11/11 PASS).

## Build

```
cc -O2 -Wall -o gart_math gart_math.c
```

## Run

```
./gart_math
```

## Expected output

Every check line prints `PASS`, ending with `ALL CHECKS PASSED (0 failures)`, demonstrating:

1. `radeon_check_arguments` (`sys/dev/drm/radeon/radeon_device.c:1117-1137`) accepts
   `drm.radeon.gart_size=8192` (power of two, ≥ 32, **no upper bound**).
2. The GTT heap then spans 8 GiB (`radeon_ttm.c:941-943`), so TTM can hand out
   `bo_mem->start = 2^20` (byte offset `2^32`, exact in `unsigned long`).
3. `radeon_gart_bind(struct radeon_device *rdev, unsigned offset, ...)` truncates that
   offset to 0 (`radeon_gart.c:286,299`) — the same GART entry index `t == 0` is produced
   for the BO at offset 0 and the BO at offset 4 GiB.
4. Consequence: the high BO's bind overwrites `pages[p]`/`pages_entry[t]`/GART PTE of the
   low BO → the GPU translates the **low** BO's aperture addresses to the **high** BO's
   physical page (cross-process GPU read/write redirection), while the high BO's true
   entries (≥ 2^20) are never written.

## Why not a kernel PoC here

The audit guest (QEMU std-VGA) has no PCI device with vendor 0x1002 (`pciconf -l` proof in
`env.txt`), so the radeon driver never attaches. The finding's precondition is additionally
a root-set boot tunable (`drm.radeon.gart_size` in `/boot/loader.conf`), i.e. a
misconfiguration-assisted defect — same precondition class as DF-2012 (amdgpu twin).