DF-5005 — amdgpu_atombios_get_clock_info() accepts usReferenceClock==0 → guaranteed amdgpu_pll_compute div0

sys/dev/drm/amd/amdgpu/amdgpu_atombios.c:592-593:

ppll->reference_freq = le16_to_cpu(firmware_info->info.usReferenceClock);

is copied from the VBIOS FirmwareInfo table without any zero check, even though the same function fixes up every neighbouring field that can be 0: pll_out_min → 64800 (:610-611), lcd_pll_out_min/max → pll_out_* (:603-608), spll/mpll pll_out_min → 64800 (:642-643, :669-670), max_pixel_clock → 40000 (:708-709). reference_freq is the odd one out — this is exactly the "latent reference_freq==0 div0" lead from the rs400/r100 family.

The value is installed into ppll[0] and cloned into every ppll[1..] (:628-629); every pixel-clock programming path then feeds it to amdgpu_pll_compute() (atombios_crtc.c:835-854 → amdgpu_pll.c:187 den = pll->reference_freq). With reference_freq == 0:

• amdgpu_pll_reduce_ratio(): gcd(nom, 0) = nom → den = 0; the denominator-minimum fixup then executes DIV_ROUND_UP(den_min, 0) → divide by zero panic at amdgpu_pll.c:63 on the first modeset with any nonzero clock;
• (if the mode clock is also 0: gcd(0,0) = 0 → *nom /= 0 at :51);
• sibling sink: spread-spectrum step-size math divides by pll->reference_freq / 100 (atombios_crtc.c:875-879) — reference_freq < 100 gives another zero divisor on the same path.

Same for the spll/mpll copies (:632-633, :659-660: usCoreReferenceClock, usMemoryReferenceClock) which feed the DPM PLL calculators.

Reproduce

Same harness as DF-5004 (verbatim amdgpu_pll.c function copies):

cc -g -O0 -Wall -o pll_harness pll_harness.c
./pll_harness ref0      # SIGFPE at amdgpu_pll.c:63 (gdb_lines.txt)
./pll_harness control   # sanity: 27 MHz reference completes fine

gdb pins the trap to pll_harness.c:114 == amdgpu_pll.c:63 (tmp = DIV_ROUND_UP(den_min, *den) with den == 0, frame shows nom_min=4, den_min=11 — den_min is post_div_min=ceil(64800/6000)=11, proving the zero is the reference frequency, not the mode clock).

Threat model

The zero comes from the VBIOS/ATOM firmware image (corrupt or malicious VBIOS, or a driver bug leaving the field unset when get_clock_info is skipped), not from runtime user input — unlike DF-2037/DF-5004. Impact is a deterministic kernel panic at first display configuration (firmware robustness / secure-boot supply-chain angle), hence Low.

Fix

fix.diff — give reference_freq the same ==0 fixup its sibling fields already get (27 MHz default for ppll; spll/mpll similarly), plus harden the consumer (amdgpu_pll.c guards, DF-5004's fix.diff).

DF-5005 VERDICT — REPRODUCED (function-level, deterministic); firmware-gated producer

Finding: amdgpu_atombios_get_clock_info() (sys/dev/drm/amd/amdgpu/amdgpu_atombios.c:592-593) copies usReferenceClock from the VBIOS FirmwareInfo table into ppll->reference_freq (and clones it to all ppll[1..3] at :628-629) with no zero check, unlike every sibling field in the same function that gets an explicit ==0 fixup (pll_out_min :610-611, lcd_pll_out_min/max :603-608, spll->pll_out_min :642-643, mpll->pll_out_min :669-670, max_pixel_clock :708-709). This answers the rs400/r100 audit lead: yes, reference_freq can be 0 from the fw-info parse and it reaches amdgpu_pll_compute (atombios_crtc.c:835-854 picks ppll[0..2] and passes the adjusted clock; amdgpu_pll.c:187 sets den = pll->reference_freq).

Reproduction (guest)

Same harness as DF-5004 — verbatim copies of amdgpu_pll.c:44-251; the ref0 case sets reference_freq = 0 with a normal 600 MHz-class mode clock (freq=60000) and the stock amdgpu_atombios.c:618-625 PLL limits:

case ref0 : freq=60000 ref=0 ... -> TRAPPED signal 8 (SIGFPE)
case control (ref=2700)          -> COMPLETED dot=14850 fb=880 ref=2 post=80

gdb (gdb_lines.txt): #0 amdgpu_pll_reduce_ratio (nom=..., den=..., nom_min=4, den_min=11) at pll_harness.c:114 — pll_harness.c:114 is the verbatim tmp = DIV_ROUND_UP(den_min, *den); i.e. amdgpu_pll.c:63, and den_min=11 is post_div_min = ceil(64800/6000) = 11, proving the zero divisor is the reference frequency (the mode clock is nonzero: 6000).

Determinism: 3/3 in the DF-5004 stress runs (pll_harness ref0 exit 42 every time), plus the dedicated run in run.log.

Why it panics

den = 0 → gcd(nom, 0) = nom (sys/dev/drm/include/linux/gcd.h: b == 0 → return a) → after the division den = 0 survives → the denominator-minimum fixup runs DIV_ROUND_UP(den_min, 0) → #DE trap → kernel panic at the first display configuration after boot/resume. If the mode clock is also 0 the first gcd itself is gcd(0,0) = 0 and *nom /= 0 traps at amdgpu_pll.c:51. Sibling sink: atombios_crtc.c:875-879 divides the spread-spectrum step size by pll->reference_freq / 100, so any firmware value < 100 is a second zero divisor on the same call chain.

Impact / threat

The trigger is a corrupt or malicious VBIOS/ATOM image (or a code path that leaves the field unset), not runtime attacker input — hence Low severity (deterministic panic = firmware-robustness / supply-chain issue; no memory corruption, no escalation). The consumer-side hardening is DF-5004's fix.diff; the producer fix is this finding's fix.diff (same ==0 fixup pattern the file already uses for its neighbours; 27 MHz default for ppll/spll, 100 MHz for mpll).

Fix validation

Producer-level: applying fix.diff replaces the 0 with 2700 — exactly the control input, which completes with sane dividers (run.log). Consumer guards (DF-5004 fix.diff) additionally make the unfixed producer complete without trapping (see DF-5004 fix_run.log, ref0 case). Kernel-level rebuild validation not possible on this guest (no AMD GPU — env.txt).

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.