# DF-4186 — radeon_device_init ignores radeon_doorbell_init() failure: NULL doorbell aperture write (WDOORBELL32) on CIK+

* File: `sys/dev/drm/radeon/radeon_device.c` (pass 2)
* Class: NULL-pointer write / panic at driver load (CWE-690), memory-pressure
  and broken-BAR2 conditional
* Hardware: AMD Sea Islands (BONAIRE/KAVERI/KABINI/HAWAII/MULLINS) and newer
  radeon-supported asics — **not present on the audit guest** (QEMU has no
  radeon GPU), so this pack is a static analysis pack.

## Root cause

`sys/dev/drm/radeon/radeon_device.c:1421-1423`:

```c
	/* doorbell bar mapping */
	if (rdev->family >= CHIP_BONAIRE)
		radeon_doorbell_init(rdev);          /* return value dropped */
```

`radeon_doorbell_init()` (`radeon_device.c:330-350`) fails with
* `-EINVAL` when BAR2 yields `num_doorbells == 0` (unassigned BAR), or
* `-ENOMEM` when `ioremap()` of the doorbell aperture fails
  (`doorbell.ptr == NULL`, but `num_doorbells > 0` and the `used` bitmap is
  already zero from the kzalloc'd device).

The dropped `-ENOMEM` case is the dangerous one: `radeon_doorbell_get()`
(`radeon_device.c:374-384`) succeeds purely on the bitmap/`num_doorbells`
state, so `cik_init()` (`cik.c:8662/8669`) stores real doorbell indices while
`rdev->doorbell.ptr` is still NULL. The first compute-ring doorbell write —
`cik_compute_set_wptr()` (`cik.c:4200-4208`):

```c
	WDOORBELL32(ring->doorbell_index, ring->wptr);   /* ((u32*)NULL)[idx] = wptr */
```

writes to the NULL page → kernel panic during `radeon_ib_ring_tests()` at
load. (The `-EINVAL` case aborts load cleanly because `doorbell_get` fails,
so the bug window is specifically ioremap failure / half-mapped BAR2.)

Upstream Linux carries the same dropped return value (verified against
torvalds/master `radeon_device.c` "doorbell bar mapping" block), so this is an
inherited latent defect, reported here for completeness.

## Trigger (requires CIK+ radeon hardware)

1. CIK+ radeon device whose BAR2 fails to ioremap at load — e.g. kernel
   virtual-address space exhausted by concurrent ioremaps (root-triggerable
   memory pressure), or a device/BIOS that leaves BAR2 assigned but unmapable.
2. `kldload radeonkms` / boot with the card present.
3. Expected: NULL-page write panic in `cik_compute_set_wptr` during
   `radeon_ib_ring_tests` — not reproducible on the audit guest (no radeon).

## Why not verified live

The audit guest is QEMU without any radeon/AMD GPU; `radeon_device_init` for
`family >= CHIP_BONAIRE` cannot execute there. Status accordingly
`not_reproduced` (device absent), confidence `likely` (the NULL-write path is
provable by inspection; the trigger conditions are hardware/mempressure-bound).

## Fix

Check the return value (fix.diff — one-liner, matches the pattern used for
every other init call in `radeon_device_init`). No runtime validation was
possible on this guest.