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:

    /* 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):

    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.

DF-4186 VERDICT

Status: not_reproduced (impact as tested: none — the audit guest has no radeon hardware; the defect is statically certain, its trigger is hardware/memory-pressure-bound). Confidence: likely.

Analysis (path:line)

• radeon_device.c:1422-1423 — if (rdev->family >= CHIP_BONAIRE) radeon_doorbell_init(rdev); return value ignored. Upstream Linux has the identical dropped check (torvalds/master), i.e. inherited defect.
• radeon_device.c:330-350 — radeon_doorbell_init fails -EINVAL (num_doorbells == 0) or -ENOMEM (ioremap fails ⇒ doorbell.ptr == NULL while num_doorbells stays > 0; the used bitmap is pre-zeroed by the kzalloc'd rdev).
• radeon_device.c:374-384 — radeon_doorbell_get allocates from the bitmap only; it cannot detect the NULL mapping.
• cik.c:8662/8669 — radeon_doorbell_get results are stored for the two compute rings during cik_init; with ptr==NULL and indices valid, load proceeds.
• cik.c:4207 — WDOORBELL32(ring->doorbell_index, ring->wptr) in cik_compute_set_wptr dereferences rdev->doorbell.ptr[index] ⇒ NULL-page write ⇒ panic during radeon_ib_ring_tests (radeon_device.c:1486).

Exploitability: write of a GPU-ring write-pointer value to the NULL page on CIK+ hardware at driver load. Practically a load-time crash under ioremap pressure / broken BAR2; not attacker-controllable content or address beyond the fixed NULL page. Low severity, availability only, root/HW-conditional.

Verification attempt

• Guest recon: dmesg/pciconf on the audit QEMU guest — no AMD/ATI PCI device exists; radeon_device_init is unreachable. No kernel rebuild can synthesize a CIK PCI device for this driver path without emulating hardware (unlike the atapi case, where the device is present and only its responses needed emulation).
• Class closed for the rest of the file: see the audit result block negative notes (rwsem asymmetry benign under DF lockmgr; golden-register callers all compile-time arrays; vram/gtt underflow is upstream-identical HW-fed math; AGP-retry fini pattern upstream-identical with guarded sub-finis).

Fix

fix.diff: propagate radeon_doorbell_init() failure (pattern already used for every sibling init call in the same function). Cannot be runtime-validated on this guest ⇒ fix_status: not_testable.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.