# DF-4413 — radeon_vm_bo_set_addr() commits mapping before PT allocation; failure leaves NULL page tables → NULL-deref panic in radeon_vm_update_ptes()

## Build

    cc -O2 -Wall -o /tmp/trigger_nullpt DF-4413/trigger_nullpt.c
    # radeon_abi.h must sit next to the .c

## Run

    /tmp/trigger_nullpt

**Requires a cayman-or-newer radeon KMS device.**

## Expected result on capable hardware

1. The program fills VRAM/GTT (and drives TTM into system memory) until the
   4 KB page-table `radeon_bo_create()` inside `radeon_vm_bo_set_addr()`
   fails.
2. `GEM_VA MAP` at 0x100000 returns an error — but the mapping has already
   been inserted into `vm->va` and `vm->cleared` (radeon_vm.c:519-526) and
   the error paths at radeon_vm.c:554-560 return **without unwinding it**.
3. The follow-up `GEM_VA UNMAP` (or any CS referencing the BO, or an
   eviction-driven invalidate) walks the full recorded range in
   `radeon_vm_update_ptes()`, hits `vm->page_tables[pt_idx].bo == NULL`
   and dereferences it at radeon_vm.c:833 (`pt->tbo.resv`) →
   **kernel panic** (NULL+offset read in kernel mode).

Success criterion: `Fatal kernel mode data access (fault va 0x…)` /
panic backtrace containing `radeon_vm_update_ptes` / `radeon_sync_resv`.

## Observed on THIS audit guest

No radeon GPU (`/dev/dri` absent; std VGA only). Trigger builds and runs,
exits at device open (see run.log). The flaw is proven by trace in
VERDICT.md.