# DF-4857 VERDICT

**Finding:** `do_div(tmp, reference_clock)` at `sys/dev/drm/radeon/rv730_dpm.c:71` divides by
`rdev->clock.spll.reference_freq`, which is copied verbatim from VBIOS
`FirmwareInfo.usReferenceClock` (`radeon_atombios.c:1189-1193`) with no zero
check. Crafted/corrupt VBIOS with `usReferenceClock==0` → fatal kernel trap
(divide error; on gcc 8.3 an `ud2` UB-guard → invalid opcode) on the DPM-enable
path for RV730/RV710.

**Status: REPRODUCED** (logic level, verbatim-replica harness on the audit
guest — the kernel-level trigger is hardware-gated: the guest has no Radeon
GPU, so `rv730_populate_sclk_value` cannot be entered in-kernel there; same
convention as DF-4492/DF-1992/DF-1937 for this driver family).

**Impact:** panic (pure DoS; no memory-corruption primitive — the divisor is
the only attacker input into the expression and the trap fires before any
memory write). No escalation chain exists for this bug class.

## How it was proven

1. **Reachability trace (source):** `radeon_device_init` → `radeon_pm_init`
   (dpm default on) → `radeon_dpm_enable` → `rv770_dpm_enable`
   (rv770_dpm.c:1956 `rv770_init_smc_table`; :1212 dispatch for RV730/RV710)
   and `rv770_convert_power_level_to_smc` (rv770_dpm.c:636) →
   `rv730_populate_sclk_value`. The division at :71 executes unconditionally
   for every engine-clock level — before the SS block at :91-107 (which is
   where DF-1937's ss.rate/clk_s divides live; DF-1937 explicitly does NOT
   cover :71).
2. **Unvalidated input (source):** `spll->reference_freq =
   le16_to_cpu(firmware_info->info.usReferenceClock)` (radeon_atombios.c:1192;
   DCE4 variant :1189-1190) — no zero check anywhere, while the *same parser*
   adds fallbacks for zero `pll_out_min` (:1173-1178, :1202-1207, :1229-1234),
   proving zero fields occur in real/corrupt images.
3. **Executable proof (guest):** `sclkdiv0.c` replicates rv730_dpm.c:40-117
   verbatim (register macros from rv730d.h:26-43, kernel-style `do_div`).
   - mode `ok`   (usReferenceClock=2700): completes, fbdiv=18204444 fits
     `SPLL_FB_DIV_MASK` — control.
   - mode `zero` (usReferenceClock=0): **fatal trap** — `Illegal instruction
     (core dumped)`, exit=132. Guest cc is gcc 8.3, which lowers the UB
     zero-division to `ud2` (confirmed via objdump in the transcript); a
     `divq` lowering yields #DE instead. In-kernel either is a hard panic
     (`Fatal trap 6/17 ... in kernel mode`).

## Fix validation

- `fix.diff` (guard `if (reference_clock == 0) return -EINVAL;` before :71 —
  identical in shape to the accepted DF-1992 fix for the rv740 twin) applied
  to the guest `/usr/src` together with DF-4858's fix; `radeon.ko` rebuilt
  **under -Werror**: compile+link OK (`radeon_module_build.log`,
  `radeon_fix_apply.log`).
- Harness with `-DFIX_DF4857`: mode `zero` returns `-EINVAL` cleanly, no
  division, exit=0 (`run.log`).
- Guest `/usr/src` reverted afterwards; `md5 rv730_dpm.c` verified back to the
  pristine `d993b8a12e7cc99729a7d82f9685be95`.

## Boundaries checked (no escalation)

- The only attacker-controlled value in the expression is the divisor; the
  quotient `fbdiv` is written into a fixed `RV770_SMC_SCLK_VALUE` struct
  (fixed-size fields, `cpu_to_be32`), not a variable-length buffer — no OOB.
- `fbdiv > SPLL_FB_DIV_MASK` (26 bits) from a crafted engine_clock would spill
  OR-bits into upper fields of `CG_SPLL_FUNC_CNTL_3` (register misprogram,
  hardware-functional only; upstream Linux identical) — hardening note, not a
  memory-safety bug; folded into the finding notes rather than filed
  separately.

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