DF-3665 VERDICT — divide-by-zero in evergreen_latency_watermark()

Reproduced? (what "reproduced" means here)

The arithmetic root cause and the divide-by-zero itself are fully proven; the kernel path cannot be executed on this audit guest because it has no radeon hardware. The guest is virtio-only (env.txt: vgapci0 ... chip=0x11111234 virtio-gpu, no /dev/dri, no drm kmods loaded), so sys/dev/drm/radeon/evergreen.c code paths are unreachable in the running kernel. Per the audit convention for hardware-absent findings, the machine verdict is inconclusive (reproduced=0) with source-level certainty documented below.

The proof chain (all path:line verified against this tree)

1. The sink. sys/dev/drm/radeon/evergreen.c:2048-2049: (512 * 8 * 1000) / available_bandwidth and (128 * 4 * 1000) / available_bandwidth are unconditional u32 divisions executed at the top of evergreen_latency_watermark() — the num_heads == 0 early-return sits at evergreen.c:2057, after the divisions.

2. Call chain to the sink. Any mode set on an enabled CRTC ends in atombios_crtc.c:1448 (radeon_bandwidth_update(rdev) inside evergreen_crtc_do_set_base) → evergreen.c:2303 evergreen_bandwidth_update() → evergreen.c:2323 evergreen_program_watermarks() → evergreen.c:2216/2218 evergreen_latency_watermark(&wm_high/&wm_low). PM clock changes reach the same code via radeon_pm.c:312/1093/1112/1142.

3. available_bandwidth can be zero — three ways (verbatim-math simulation in df3665.c, executed on the guest; see run.log):

a. User-controlled mode clock 1..38 kHz. radeon_display.c:1350 radeon_mode_funcs has no .mode_valid, so drm_mode_convert_umode() (drm_modes.c, calls drm_mode_validate_driver → drm_mode_validate_basic at drm_modes.c:1103-1130) only rejects clock == 0 — 25 kHz passes. wm.disp_clk = mode->clock (evergreen.c:2172) → evergreen_dmif_request_bandwidth() (evergreen.c:1989-2007) computes trunc(32 * (25/1000) * 0.8) = 0 → min() at evergreen.c:2016 → 0. b. u32 fixed-point wrap. drm_fixed.h:32-42: fixed20_12 is a u32; dfixed_const(A) = (u32)(A << 12). Inputs are wm->yclk = mclk*10 / wm->sclk = sclk*10 (evergreen.c:2163-2169, 2190-2196), so any clock ≥ 104,857.6 kHz wraps. Exhaustive scan (0..4 GHz, step 1 kHz, u32 semantics): 351 mclk values zero evergreen_dram_bandwidth() — including exactly 524288, 1048576, 1572864 kHz and the k·2^20/10 wrap bands (419431 kHz shown) — and 156 sclk values zero evergreen_data_return_bandwidth(). These clocks are VBIOS/DPM-controlled (rdev->pm.current_mclk/sclk, radeon_dpm_get_mclk/sclk). c. VBIOS zero clocks (FirmwareInfo reporting mclk/sclk = 0, the DF-1708 class) trivially zero the bandwidth.

4. The trap. In-kernel, u32 / 0 on x86-64 raises #DE → kernel panic. The PoC executes the exact division (divisor fed through a pipe so the compiler cannot fold it) in forked children: 9/9 divisor-zero scenarios died with SIGFPE (run.log), the userspace manifestation of the same fault. The three control scenarios (typical HD5870/HD5770/sumo clocks) returned 2851/1900/487 — nonzero, no trap — demonstrating the boundary is exactly where the math says it is (clock = 39 kHz → 1; clock = 38 kHz → 0).

Why not "reproduced"/panic on the guest

The guest kernel would panic at evergreen.c:2048 on the first bandwidth_update after such a mode set — but there is no Evergreen GPU in the QEMU guest (virtio display only), so /dev/dri/radeon cannot exist and the ioctl path cannot run. Building a patched kernel to "validate the fix" is likewise not testable without the device; fix.diff is validated by inspection (it moves the divisions behind a zero-guard, mirroring the arithmetic the PoC demonstrates).

Threat model

• Local user with DRM-master rights (console user, X session, or any local user when no other master holds the device) submits a DRM_IOCTL_MODE_SETCRTC user mode with clock ≤ 38 kHz → immediate kernel panic (path 3a needs no unusual hardware state at all beyond an Evergreen-class radeon).
• Conversely, unlucky-but-realistic VBIOS/DPM memory or engine clock values (524.288 MHz, 1048.576 MHz, ...) panic on the first mode set at boot or on the first DPM level change (paths 3b/3c).

Impact: reliable local denial of service (kernel panic). No memory corruption, no privilege escalation. Severity Medium, consistent with the audit's precedent for VBIOS-divisor panics (DF-1386, DF-1650, DF-1137).

Fix

Guard the divisor (and while there, guard wm->disp_clk for line 2050) — see fix.diff:

    u32 mc_latency = 2000; /* 2000 ns. */
    u32 available_bandwidth = evergreen_available_bandwidth(wm);
+   if (!available_bandwidth || !wm->disp_clk)
+       return 0;
    u32 worst_chunk_return_time = (512 * 8 * 1000) / available_bandwidth;

Returning 0 makes the watermark "no latency hiding required", which is the safe fallback the function already uses for num_heads == 0. A deeper fix (out of scope for a minimal security patch) would keep the fixed-point math in 64-bit so the dfixed_const() wrap stops corrupting every watermark above 1 GHz inputs.

Cross-references

• Same-family audit findings: DF-1386 (cypress burst time), DF-1650 (rs780 drm_mode_vrefresh), DF-1431 (radeon pll sub-10 kHz clock).
• The u32 fixed20_12 wrap additionally makes all DCE4/5 watermark values garbage for mclk ≥ 104.86 MHz — a correctness issue upstream shares; only the zero-window values are security-relevant.

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.