DF-4153 — Zero VBIOS reference clocks stored unchecked reach PLL/SS divisions (#DE panic) — amdgpu twin of DF-3742

File: sys/dev/drm/amd/amdgpu/amdgpu_atombios.c (pass 2)

Reproduced?

No — hardware-gated (no AMD GPU on the audit guest; see env.txt). Established at source level.

Source trace

amdgpu_atombios_get_clock_info() copies three BIOS-provided reference clocks with no zero/validity check — unlike the neighboring limits which are defaulted (pll_out_min == 0 → 64800 at :610-611, :642-643, :669-670, max_pixel_clock == 0 → 40000 at :708-709):

592:  ppll->reference_freq = le16_to_cpu(firmware_info->info.usReferenceClock);
632:  spll->reference_freq = le16_to_cpu(firmware_info->info_21.usCoreReferenceClock);
659:  mpll->reference_freq = le16_to_cpu(firmware_info->info_21.usMemoryReferenceClock);

ppll[0..AMDGPU_MAX_PPLL-1] are populated by the struct copy at :628-629, and adev->pm.current_sclk/mclk derive from the same table (:677-719).

Downstream divisions with no intervening zero check (grep for reference_freq == 0 across sys/dev/drm/amd/amdgpu/ finds nothing):

1. Mode set / PLL compute — amdgpu_pll.c:187 den = pll->reference_freq (for pixel PLLs = ppll[].reference_freq), then amdgpu_pll.c:92 *fb_div = DIV_ROUND_CLOSEST(nom * *ref_div * post_div, den) → integer division by zero (gcd(nom,0) at :50 is safe — the libkern while (b) loop skips — but den survives as 0 to :92). Every CRTC mode program via amdgpu_pll_compute reaches this.
2. Spread-spectrum step size — atombios_crtc.c:876 and :879: step_size = (...) / (125 * 25 * pll->reference_freq / 100); — the denominator collapses to 0 when reference_freq == 0 → #DE during amdgpu_atombios_crtc_program_pll when SS is enabled (SS comes from the same VBIOS, amdgpu_atombios_get_asic_ss_info).
3. DPM-side consumers (si_dpm.c:5257/5379, ci_dpm.c:2122/2970/3313, cik.c:842-851, vi.c:328-342) propagate the zero into clock conversions with further divides.

Sibling (noted, different file): amdgpu_atomfirmware.c:290/313 sets the same fields from atomfirmware tables, also unchecked.

Trigger: crafted VBIOS with usReferenceClock == 0 (or the info_21 fields for sclk/mclk paths) — driver attach succeeds; first mode set (or DPM init) faults with a kernel divide error → local DoS / panic. This is exactly the pattern accepted as Medium for radeon (DF-3742).

Verdict

INCONCLUSIVE (hardware-gated / not reachable on the audit guest). Source-certain: unchecked zero reaches at least two concrete division sites. Severity Medium (crafted-VBIOS local DoS via panic; hardware-gated delivery).

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.