# DF-4696 VERDICT — divide-by-zero at dcn10_dpp_dscl.c:439-441

**Status: not_reproduced on the audit guest — target hardware absent
(no AMD GPU under QEMU). The exploit chain is proven statically link by
link, and the exact arithmetic (producer formulas + faulting division)
was executed on the guest as a userland twin: the attack geometry makes
the divisor exactly 0 and the division faults (SIGFPE, exit 136), the
control geometry does not.**

## Reproduction attempt (honest)

- Guest: DragonFly 6.5-DEVELOPMENT `#0 Thu Jul 2 06:02:54 UTC 2026`
  (X86_64_GENERIC), QEMU std VGA only; `/dev/dri` does not exist; no
  vendor-0x1002 PCI device (env.txt). `dcn10_dpp_dscl.c` compiles into
  the amdgpu DC module, which cannot attach — the kernel path is
  unreachable at runtime on this guest. Same situation as DF-4373
  (the DCE sibling of this bug family).
- Probe + arithmetic twin built with base cc 8.3 and run 3×:
  control case completes (`num_part_y` clamped to 64); attack case dies
  with SIGFPE every run (run.log, run.2.log). Intermediate values match
  the static chain exactly: `viewport.width=640 recout.x=640
  recout.width=0 line_size=0 memory_line_size_y=0` → `816/0`.
- PoC-code note (poc_changes): the first harness version let gcc8
  exploit the C UB of `816/0` with a constant numerator and silently
  replaced the division (no fault — build_first_attempt.log /
  run_raw log). The kernel's divisor is a runtime value, which compiles
  to a real `idiv` and faults (cf. DF-4582, an integer-divide panic
  *reproduced* on this guest as trap 18). The harness now hides the
  divisor behind an asm barrier, forcing the real divide instruction —
  SIGFPE is the faithful twin of the kernel #DE.

## Why the kernel bug is real (static chain, every link cited)

1. **UABI reachability.** Modesetting needs DRM master; the session user
   of any seat/desktop holds it (no root). The faulting path runs during
   the atomic *commit* (program-front-end), reached from
   `amdgpu_dm_atomic_check`-validated, `dc_validate`-accepted state.

2. **Plane rects are never clipped to the CRTC.**
   `fill_rects_from_plane_state` (amdgpu_dm.c:2210-2240) copies raw
   `crtc_x/y/w/h`, rejects only zero dimensions, sets
   `clip_rect = dst_rect`. `dm_plane_atomic_check`
   (amdgpu_dm.c:3585-3603) only calls fill_rects + `dc_validate_plane`
   ("validates pixel format only", dc_resource.c:2891-2900);
   `dcn10_validate_plane` (dcn10_resource.c:1131-1138) checks video src
   width only. Nothing anywhere rejects an off-CRTC plane position.

3. **The only degeneracy guard tests the wrong rectangle.**
   `resource_build_scaling_params` (dc_resource.c:1104) returns failure
   only when `viewport.height < 16 || viewport.width < 16`
   (dc_resource.c:1125-1127) — and `viewport.width` is in SOURCE pixels
   (dc_resource.c:543: `clip.width * src.width / dst.width`). A plane
   with a 640-wide source shown at CRTC_W=1 keeps viewport.width = 640:
   the guard passes. `recout` is computed *after* the guard
   (dc_resource.c:1129) and is never checked.

4. **recout clamps to exactly zero.** `calculate_recout`
   (dc_resource.c:615-706): with stream dst = [0,640) and plane
   CRTC_X=640, CRTC_W=1: `recout.x = 0 + (640-0)*640/640 = 640`;
   `recout.width = 1*640/640 = 1`; clamp at :639-643:
   `recout.width = (0+640) - 640 = 0`. Exactly zero, signed ints, no
   underflow. (Second zero source, no positioning trick needed:
   underscan hborder insets stream->dst while src stays full mode —
   `recout.width = clip.w * dst.w / src.w = 0` for a small plane.)

5. **DCN10 validation has no guard here.** `dpp_get_optimal_number_of_taps`
   (dcn10_dpp.c:141-210) computes `pixel_width = min(viewport.w,
   recout.w)` at :148-151 — and never reads it; it returns true
   unconditionally (non-FP16). This dead variable is exactly where the
   DCE sibling (DF-4373) crashes, and its deadness here is why DCN10
   validation *accepts* the config. `validate_bandwidth`
   (dcn_calcs.c) consumes viewport.width (≥16) and copies recout.width
   into bw variables but never divides by it on this geometry.

6. **Commit path reaches the sink unconditionally.** Full update:
   `dcn10_update_dchubp_dpp` (dcn10_hw_sequencer.c:2101-2104, flags
   full_update/scaling/position) → `update_scaler` (:2029-2041, sets
   lb depth 30BPP) → `dpp1_dscl_set_scaler_manual_scale`
   (dscl.c:647): memcmp first-program passes; format XRGB8888 (≠FP16)
   so no DSCL_MODE_DSCL_BYPASS early return (:684-685); ratios ≠ 1 →
   not 444_BYPASS either;
   `dpp1_dscl_find_lb_memory_config` (:463, `dc->debug.use_max_lb`
   false — `dc` is kzalloc'd, dc.c:729-732, no later assignment) →
   first call `dscl_calc_lb_num_partitions(scl_data,
   LB_MEMORY_CONFIG_1, ...)` (:476) → **`816 / 0` at :439** → #DE →
   kernel panic.

7. **Sibling precedent.** DF-4373 (dce_transform.c) is the same
   producer chain crashing in the DCE validation path; DF-4582 proved
   this guest *does* panic on integer divide-by-zero in kernel code
   (trap 18) when the path is reachable.

## Impact

Local DoS (kernel panic) by an unprivileged session user (DRM master)
on DragonFly machines with a DCN1.0 (Raven) AMD GPU driven by the
in-tree amdgpu DC. Not memory corruption; no privilege escalation
avenue — integer #DE is a trap, not a controllable primitive.

## Fix validation

Not possible on this guest: no AMD GPU, so the amdgpu module cannot
attach and neither baseline nor patched kernel can exercise the path
(fix_status = not_testable). `fix.diff` guards the three divisors
(<= 0, which also covers the lb_bpc == -1 unsupported-depth path) and
returns zero partitions; `dpp1_dscl_is_lb_conf_valid` then fails every
configuration (vtaps >= 1 vs num_partitions 0), so the caller falls
through to the default LB config with the existing ASSERT warning
instead of dividing. No other caller of `dscl_calc_lb_num_partitions`
exists (grep: dcn10_dpp.c:535 registration, internal calls only).

## Artifacts

- `trigger_df4696.c` — device probe + arithmetic twin (control/attack)
- `build.sh` / `run.sh` — exact commands
- `build.log` (final), `build_first_attempt.log` (UB-pitfall record),
  `run.log`, `run.2.log` (3 runs, SIGFPE every time)
- `env.txt` — guest uname, compiler, GPU absence evidence
- `fix.diff` — divisor guard, authored against the read-only tree
- `manifest.json` / `verdict.json`

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