# 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.