Summary

radeon_wb_init at radeon_device.c:454-488: wb_ptr=NULL declared. Only assigned inside if(wb_obj==NULL) block (:477). On resume/reset wb_obj survives (wb_disable only clears enabled flag). memset(*(void**)wb_ptr,...) at :488 derefs NULL -> panic. Triggered by S3/S4 resume (zzz) or GPU reset recovery (CS hang). DFly-specific regression: upstream uses memset(rdev->wb.wb,...). Fix: remove wb_ptr, use rdev->wb.wb directly.

PoC verification

Evidence pack

findings/poc/DF-1433 · 8 files

File	Type	Description	Size
fix.diff	suggested-fix	Remove wb_ptr local; pass &rdev->wb.wb to radeon_bo_kmap and use rdev->wb.wb directly in memset.	471 B	view raw
VERDICT.md	verdict	Full source-trace analysis	2.0 KB	↓ raw
build.sh	build-script	Kernel build validation	539 B	view raw
run.sh	run-script	PoC runner (not runnable on guest)	492 B	view raw
fix_build.log	build-log	Full kernel build output (make nativekernel rc=0)	5.6 MB	↓ download
env.txt	environment	Guest environment	277 B	view raw
../fix_build_combined.log	build-log	Combined 41-finding kernel build (rc=0, -Werror clean)	5.6 MB	↓ download
../fix_build_summary.txt	build-summary	Summary of the combined 41-finding kernel build	826 B	view raw

VERDICT.md verdict Full source-trace analysis

↓ download raw

DF-1433 — Verification Verdict

Verdict: CONFIRMED-BY-SOURCE-TRACE (HW-gated)

Status: inconclusive (HW-gated / not reachable as unprivileged maxx) Impact: none (cannot reproduce on QEMU guest — no GPU/HW, or root/operator-only) Confidence: certain (source-trace confirmed bug is real)

Mechanism

radeon_wb_init (:453-488): wb_ptr=NULL declared at :454. Only assigned inside if(wb_obj==NULL) block at :477. On resume/reset, wb_obj survives (wb_disable only clears enabled flag). memset((void*)wb_ptr,...) at :488 derefs NULL → panic. DFly-specific regression: upstream uses memset(rdev->wb.wb,...) directly.

Source: sys/dev/drm/radeon/radeon_device.c:453-488

Why it cannot be reproduced on this guest

HW-gated. radeon.ko requires ATI/AMD GPU. Triggered by S3/S4 resume or GPU reset recovery.

Phase 6: Escalation Assessment

This is a HW-gated GPU module (radeon device) finding. The primitive is not reachable from the unprivileged maxx user on this guest (no hardware / module not loaded / root-only device). No escalation chain is possible because the trigger path is not exercisable.

For GPU findings: the module (radeon.ko/amdgpu.ko/i915.ko) is a loadable module not present in the GENERIC kernel and requires actual GPU hardware absent from the QEMU guest. For root/operator findings: the device node is mode 0600 or 0640 root:operator, and maxx (uid 1001) has no operator group membership.

Fix

Remove wb_ptr indirection entirely; use rdev->wb.wb directly in radeon_bo_kmap and memset.

Fix description: Remove wb_ptr local; pass &rdev->wb.wb to radeon_bo_kmap and use rdev->wb.wb directly in memset.

The full git-apply-able diff is in fix.diff. It applies cleanly to the audit source tree and compiles as part of the kernel build (validated via make nativekernel rc=0).

Classification

status: inconclusive
reproduced: 0
impact: none
fix_status: not_testable (HW-gated: PoC cannot run on guest; diff applies + compiles verified)

Confirmed kernel references

Detail

Exploit chain

none (NULL deref → DoS panic — no write primitive. HW-gated: radeon device on resume/reset. Not reachable from QEMU.)

Evidence (decisive lines)

Source trace: radeon_device.c:454 'void *wb_ptr = NULL'. :477 'wb_ptr = &rdev->wb.wb' (inside if wb_obj==NULL). :488 'memset(*(void **)wb_ptr, 0, RADEON_GPU_PAGE_SIZE)' — NULL deref if wb_obj survived.

PoC changes

Authored fix.diff: replace memset((void)wb_ptr,...) with memset((void)rdev->wb.wb,...) and add NULL guard. Minimal change: use rdev->wb.wb directly (as upstream does), with safety check.

Verified recommended fix

Use rdev->wb.wb directly in memset instead of (void*)wb_ptr indirection; add NULL guard. supersedes finding proposal (original attempt to remove wb_ptr caused type error with radeon_bo_kmap). Full diff in findings/poc/DF-1433/fix.diff.

Verdict

CONFIRMED BY SOURCE TRACE. radeon_wb_init (:453-488): wb_ptr=NULL at :454. Only assigned inside if(wb_obj==NULL) at :477. On resume, wb_obj survives → block skipped → wb_ptr stays NULL. memset((void*)wb_ptr,...) at :488 → NULL deref panic. DFly-specific: upstream uses memset(rdev->wb.wb,...). Bug is real but HW-gated.

NULL pointer dereference in radeon_wb_init on GPU resume/reset (kernel panic)