DF-3648 — Integer divide-by-zero on zero MPLL/SPLL reference clock in ci_calculate_mclk_params (usMemoryReferenceClock stored unchecked)

File: sys/dev/drm/radeon/ci_dpm.c (pass 2, GLM 5.3 re-audit) Severity: Medium | CWE-369 Divide By Zero | confidence: certain

Reproduce

This pack carries a userland logic harness (harness.c) built and run ON THE AUDIT GUEST with the exact kernel types; decisive section: [C]

./build.sh
./run.sh

Expected decisive line: SIGFPE (kernel: #DE panic)

The kernel code path itself requires a Sea Islands radeon GPU + crafted VBIOS; the guest is virtio-only (no AMD PCI device, no /dev/dri, no drm kld) — see env.txt.

Full narrative: VERDICT.md. Proposed fix: fix.diff (authored against the read-only sys/ tree; never applied there).

DF-3648 — verdict narrative

Finding

Integer divide-by-zero on zero MPLL/SPLL reference clock in ci_calculate_mclk_params (usMemoryReferenceClock stored unchecked)

Kernel references

• sys/dev/drm/radeon/ci_dpm.c:2865
• sys/dev/drm/radeon/ci_dpm.c:2872
• sys/dev/drm/radeon/ci_dpm.c:3203
• sys/dev/drm/radeon/ci_dpm.c:3227
• sys/dev/drm/radeon/ci_dpm.c:3228
• sys/dev/drm/radeon/radeon_atombios.c:1216
• sys/dev/drm/radeon/radeon_atombios.c:1221

Was it reproduced?

No — not on the kernel path. The audit guest is virtio-only (0 AMD PCI devices, /dev/dri absent, no radeon/drm kld; env.txt), so sys/dev/drm/radeon/ci_dpm.c can never execute there. Per the pass-2 instruction for this hardware-gated file, the verdict is inconclusive (source-level certainty certain) rather than reproduced.

Logic-level proof (guest harness)

harness.c models the exact loop/index/division with the exact kernel types and was compiled and executed on the audit guest (cc -O2 -Wall, DragonFly 6.5-DEVELOPMENT). Decisive output, stable across 2 runs (run.log, run.2.log):

SIGFPE (kernel: #DE panic)

Root cause and reasoning

Source-certain div-by-zero, radeon/ci twin of DF-3613 (si) / DF-3622 (amdgpu ci). radeon_atombios_get_clock_info stores usMemoryReferenceClock (DCE4+ path, radeon_atombios.c:1216-1218; CI is DCE8) into rdev->clock.mpll.reference_freq with no sanity check; a crafted FirmwareInfo with that field 0 leaves reference_freq == 0. ci_calculate_mclk_params reads it (ci_dpm.c:2865) and divides tmp = freq_nom / reference_clock (2872) inside the caps_mclk_ss_support block - #DE panic. The sclk path is affected indirectly: clk_s = reference_clock * 5 / (ref_div * ss.rate) evaluates to 0 when reference_clock == 0, and the very next line divides by it (clk_v = ... / (clk_s * 10000), ci_dpm.c:3228) - div-by-zero again. On-guest harness section [C] proved 300000/0 faults with SIGFPE. Kernel path unreachable on this GPU-less guest; inconclusive overall.

Exploitability

Crafted VBIOS whose FirmwareInfo reports usMemoryReferenceClock (or the pre-DCE4 usReferenceClock) as 0, with the SS info table present so caps_*_ss_support is set -> u32 divide by zero at DPM table population -> panic at load. DoS only.

Recommended fix

Skip SS programming (or fail DPM init) when rdev->clock.{mpll,spll}.reference_freq is 0. See fix.diff.

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.