Summary

radeon_compute_pll_avivo at radeon_display.c:959: target_clock=freq/10. freq=mode->clock from DRM_IOCTL_MODE_SETCRTC. DRM core rejects only clock==0. clock 1-9 -> target_clock=0 -> :1012 vco_min/target_clock -> #DE panic. AVIVO+ ASICs. Local unprivileged (video group). Fix: floor freq>=10, guard post_div_max==0.

PoC verification

Evidence pack

findings/poc/DF-1431 · 8 files

File	Type	Description	Size
fix.diff	suggested-fix	Add `if (target_clock == 0) return;` guard after freq/10 computation.	458 B	view raw
VERDICT.md	verdict	Full source-trace analysis	1.9 KB	↓ raw
build.sh	build-script	Kernel build validation	540 B	view raw
run.sh	run-script	PoC runner (not runnable on guest)	454 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-1431 — 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_compute_pll_avivo (:959): target_clock=freq/10. freq=mode->clock from DRM_IOCTL_MODE_SETCRTC. DRM core rejects only clock==0. clock 1-9 → target_clock=0 → :1012 post_div_max=vco_max/target_clock → #DE panic. AVIVO+ ASICs.

Source: sys/dev/drm/radeon/radeon_display.c:959, 1012

Why it cannot be reproduced on this guest

HW-gated. radeon.ko requires ATI/AMD AVIVO+ GPU. No GPU in QEMU guest.

Phase 6: Escalation Assessment

This is a HW-gated GPU module (radeon display) 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

Guard target_clock==0: return early from radeon_compute_pll_avivo if target_clock is 0.

Fix description: Add if (target_clock == 0) return; guard after freq/10 computation.

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 (div-by-zero DoS — no write primitive. HW-gated: radeon display on ATI/AMD GPU. Not reachable from QEMU.)

Evidence (decisive lines)

Source trace: radeon_display.c:959 'unsigned target_clock = ... freq : freq / 10' — if freq is 1-9, target_clock=0. :1012 'post_div_max = vco_max / target_clock' — div-by-zero.

PoC changes

Authored fix.diff: add 'if (target_clock == 0) return;' guard after freq/10 computation.

Verified recommended fix

Guard target_clock==0: return early from radeon_compute_pll_avivo if target_clock is 0. matches finding proposal. Full diff in findings/poc/DF-1431/fix.diff.

Verdict

CONFIRMED BY SOURCE TRACE. radeon_compute_pll_avivo (:959): target_clock=freq/10. freq=mode->clock from DRM_IOCTL_MODE_SETCRTC. DRM core rejects only clock==0. clock 1-9 → target_clock=0 → :1012 post_div_max=vco_max/target_clock → #DE div-by-zero panic. Bug is real but HW-gated: radeon.ko requires AVIVO+ ASIC.

Divide-by-zero in radeon_compute_pll_avivo via sub-10 kHz mode clock