DF-5004 — amdgpu_pll_compute() divide-by-zero via degenerate derived dividers (fb_div==0 / ref_div==0)

New pass-2 sinks in sys/dev/drm/amd/amdgpu/amdgpu_pll.c, distinct from the known DF-2037 (target_clock==0 / post_div==0). Here target_clock and post_div are NONZERO; the derived quantities under-run to zero and are then used as divisors:

1. fb_div → 0, panic at amdgpu_pll.c:56 Small-but-nonzero target_clock (freq/10 ∈ [1, ~ref_freq/254], e.g. freq=55 → tc=5 with the standard 27 MHz reference): post_div_min = ceil(64800/5) = 12960 > post_div_max=127 → empty search loop → post_div = 127 → ref_div_max = min(128/127,1023) = 1 → fb_div = DIV_ROUND_CLOSEST(nom*1*127, den) = 0 → amdgpu_pll_reduce_ratio(fb_div=0, ref_div=1, 4, 2): gcd(0,1)=1 → nom=0 → DIV_ROUND_UP(4, 0) divide by zero. (DF-2037 only covers tc==0, i.e. freq<10; the window freq ∈ [10,109] is one decade above it and was NOT covered.)
2. ref_div → 0, panic at amdgpu_pll.c:203 AMDGPU_PLL_USE_POST_DIV with pll->post_div ≥ 129 (settable from the AdjustDisplayPll firmware output ucPostDiv, a u8, at atombios_crtc.c:441-442): ref_div_max = min(128/post_div,1023) = 0 → ref_div = min(max(...,1u), 0) = 0 → in the diff loop (reference_freq*fb_div) / (ref_div*post_div) = 0/0 divide by zero. (Variant: an unclamped post_div_min > 128 combined with AMDGPU_PLL_PREFER_MINM_OVER_MAXP — flag is never set by amdgpu callers today, noted as dead route.)

In the kernel these are divu/idiv by zero → #DE trap → panic. Same call path and same attacker as DF-2037: a DRM-master/VT user issues a modeset with a degenerate dot clock; the mode clock reaches amdgpu_pll_compute() unvalidated via atombios_crtc.c:854 (amdgpu_crtc->adjusted_clock, guarded only against == 0).

Reproduce

Run on the DragonFly guest (or any Unix with a C compiler):

./build.sh          # cc -g -O0 -o pll_harness pll_harness.c
./run.sh            # control / tc5 / ref0 / pd200, one process each

Expected: control completes with sane dividers (dot=14850 fb=880 ref=2 post=80); tc5, ref0, pd200 each die with SIGFPE (integer divide by zero). gdb_lines.txt pins the trapping source lines inside the verbatim function copies:

tc5   → pll_harness.c:107  == amdgpu_pll.c:56  (DIV_ROUND_UP(nom_min, *nom=0))
ref0  → pll_harness.c:114  == amdgpu_pll.c:63  (DIV_ROUND_UP(den_min, *den=0))
                                  [that sink is filed separately as DF-5005]
pd200 → pll_harness.c:228  == amdgpu_pll.c:203 ((ref_freq*fb_div)/(ref_div*post_div) = 0/0)

The harness reproduces amdgpu_pll_reduce_ratio / amdgpu_pll_get_fb_ref_div / amdgpu_pll_compute verbatim (sys/dev/drm/amd/amdgpu/amdgpu_pll.c:44-251) with the tree's own gcd64() and DIV_ROUND_* semantics, and the PLL limits programmed for every pixel PLL at amdgpu_atombios.c:618-625.

Why no in-kernel run on the guest

The audit QEMU guest has no AMD GPU (only a bochs/QEMU std VGA — see env.txt), so amdgpu never attaches and the DRM modeset path cannot be driven in-kernel there. The divide-by-zero is a pure arithmetic property of the (verbatim-copied) function and is proven deterministically in userland; in-kernel it is the same division on the same values (trap 0 → panic). DF-2037 (pass 1) was verified the same way ("source-only"), this pack is strictly stronger: executable + gdb line-level + 3× determinism + fix validation (fix_run.log: patched functions complete all cases, control output bit-identical).

DF-5004 VERDICT — REPRODUCED (function-level, deterministic)

Finding: amdgpu_pll_compute() divides by zero when derived dividers under-run to zero — fb_div == 0 (small nonzero target_clock) or ref_div == 0 (post_div ≥ 129 via AMDGPU_PLL_USE_POST_DIV) — trapping at amdgpu_pll.c:56 / amdgpu_pll.c:203 (and :51 via gcd(0,0)==0 for the overlap). This is distinct from DF-2037, whose sinks are amdgpu_pll.c:172/:178 (target_clock == 0) and :88/:91/:242 (post_div == 0): in every case here target_clock != 0 and post_div != 0.

How it was reproduced

pll_harness.c contains verbatim copies of sys/dev/drm/amd/amdgpu/amdgpu_pll.c:44-251 (amdgpu_pll_reduce_ratio, amdgpu_pll_get_fb_ref_div, amdgpu_pll_compute), with gcd64() matching sys/dev/drm/include/linux/gcd.h exactly (gcd(0,0)==0, gcd(x,0)==x) and DIV_ROUND_UP/DIV_ROUND_CLOSEST matching sys/dev/drm/include/linux/kernel.h. PLL limits are the ones the driver installs for every pixel PLL (amdgpu_atombios.c:618-625): min/max_post_div = 2/127, min/max_ref_div = 2/1023, min/max_feedback_div = 4/4095, reference_freq = 2700 (27 MHz), pll_out_min = 64800 (the driver's own ==0 fixup floor at amdgpu_atombios.c:610-611).

Built and executed on the audit QEMU guest (DragonFly dfbsd 6.5-DEVELOPMENT #0 ... x86_64, see env.txt):

gdb_lines.txt (gdb -batch, -g -O0 build) pins each trap to the exact statement inside the verbatim copy: harness:107==amdgpu_pll.c:56, harness:114==amdgpu_pll.c:63, harness:228==amdgpu_pll.c:203, with the frame arguments showing the zeros (nom=0, den_min=11 for ref0 — i.e. post_div_min=11 exactly as derived from ceil(64800/6000)).

Determinism: 3/3 runs identical (run.2.log).

Arithmetic derivation (why the zeros are forced, not contrived)

tc5: post_div_min = ceil(64800/5) = 12960 is never clamped down to max_post_div (amdgpu_pll.c:172-176 only clamps up to min_post_div), the search loop at :199 is empty (12960 > 127), post_div = post_div_max = 127 (:196), ref_div_max = min(128/127, 1023) = 1 (:88), so fb_div = DIV_ROUND_CLOSEST(nom·1·127, den) = round(127·tc/ref) = 0 for tc < ref/254 (tc=5, ref=2700), then amdgpu_pll_reduce_ratio(0, 1, 4, 2) at :221 divides DIV_ROUND_UP(4, 0) at :56.

pd200: post_div_min = post_div_max = pll->post_div = 200 (:154-155, from atombios_crtc.c:441-442 firmware ucPostDiv), ref_div_max = min(128/200, 1023) = 0 (:88), ref_div = min(max(x,1u), 0) = 0 (:91), fb_div = 0 (:92), and the first loop iteration computes (reference_freq * 0) / (0 * 200) at :203.

In-kernel reachability

Same chain DF-2037 established: DRM-master/VT user modeset with attacker chosen dot clock → dce_v*_pick_pll → amdgpu_atombios_crtc_pll (atombios_crtc.c:812,:854) → amdgpu_pll_compute(adev->clock.ppll[0..2], adjusted_clock, ...). The tc∈[1,10] window (dot clock 0.10–1.09 MHz) sits one decade above DF-2037's freq<10 window; the pd200 window additionally requires the VBIOS AdjustDisplayPll command to return a post divider > 128. In-kernel a div by zero raises #DE → kernel trap → panic: local DoS. No memory corruption, no escalation path — the primitive is a trap only.

Guest caveat: the audit guest has no AMD GPU (env.txt: only vgapci0: Red Hat/virtio = bochs std VGA), so amdgpu cannot attach and an in-kernel modeset repro is impossible on this guest; the function-level proof above is on the verbatim code and the in-kernel division is the same instruction on the same values. DF-2037's pass-1 verification was accepted at the same ("source-only") standard; this pack is strictly stronger (executable, gdb line-pinned, 3× determinism, fix-validated).

Fix validation (function level)

fix.diff adds three guards (reduce_ratio zero-floors; post_div floor and ref_div_max ≥ 1 in get_fb_ref_div). Applied 1:1 to the harness copy (pll_harness_fixed.c, built on guest — fix_run.log):

Kernel-level rebuild validation is not possible on this guest (no AMD GPU to drive the modeset path), recorded as such in verdict.json:fix_verdict.

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.