# DF-1253 — uint32 underflow in vega20_apply_clocks_adjust_rules (count-1 wraps to UINT32_MAX)

## Verdict
**SOURCE-CONFIRMED (real bug), INCONCLUSIVE at runtime** — the `amdgpu.ko` module is not loaded (no AMD Vega20 GPU in the QEMU guest) and is not in the GENERIC kernel, so the underflow path is dormant. Fix authored and compile-validated.

## Mechanism (source trace)
`vega20_apply_clocks_adjust_rules()` iterates over the MCLK latency table using a `uint32_t count - 1` loop bound with no zero-guard:

- `sys/dev/drm/amd/powerplay/hwmgr/vega20_hwmgr.c:3095-3104`:
  ```
  if (disable_mclk_switching) {
      dpm_table->dpm_state.hard_min_level = dpm_table->dpm_levels[dpm_table->count - 1].value;
      for (i = 0; i < data->mclk_latency_table.count - 1; i++) {     /* <- UNDERFLOW */
          if (data->mclk_latency_table.entries[i].latency <= latency) {
              if (dpm_table->dpm_levels[i].value >= ...) { ... }
          }
      }
  }
  ```
- `data->mclk_latency_table.count` is `uint32_t` (`vega20_hwmgr.h:267`), default 0 after kzalloc. It is set non-zero **only** by `vega20_get_memclocks()` (`vega20_hwmgr.c:2435`). If `vega20_apply_clocks_adjust_rules` runs before `vega20_get_memclocks` populates the table, `count - 1` wraps to `0xFFFFFFFF` ⇒ the loop iterates ~4 billion times, reading `entries[i]` and `dpm_levels[i]` OOB past their `MAX_REGULAR_DPM_NUMBER=16` arrays (`vega20_hwmgr.h:159,268`).
- `disable_mclk_switching` is `true` when `1 < num_display && !multi_monitor_in_sync` (multi-monitor out of sync) or `vblank_too_short` (`vega20_hwmgr.c:3037-3039`) — a plausible state on a multi-monitor Vega20 system when display config changes.
- The same `count - 1` OOB pattern also appears at lines 3045/3047/3069/3071/3096/3108 for `dpm_table->count`, though those are guarded by `vega20_setup_default_dpm_tables` setting `count >= 1` (`vega20_hwmgr.c:598`).

## Why not reproduced at runtime
- `amdgpu.ko` is **not loaded** on the guest and is **not in X86_64_GENERIC**.
- Requires an AMD Vega20 GPU (Radeon VII / Vega 20); QEMU guest has no AMD GPU.
- On real hardware, an unprivileged user changing display config (hotplug, mode set) could influence `num_display`/`multi_monitor_in_sync` and trigger the underflow if the power-management state machine calls `apply_clocks_adjust_rules` before `get_memclocks`.

## Fix (fix.diff, compile-validated)
1. Guard `dpm_table->count == 0` before the `count - 1` accesses in the `disable_mclk_switching` and `nb_pstate_switch_disable` blocks (skip via a `goto skip` / early return).
2. Rewrite the latency loop bound as `i + 1 < data->mclk_latency_table.count` (no underflow when count is 0) and add a hard `i < MAX_REGULAR_DPM_NUMBER` cap as defense-in-depth.

The patched `vega20_hwmgr.c` compiles cleanly with gcc 8.3, `-Werror`, no warnings.

## Realistic impact ceiling
Kernel heap OOB read (entries[]/dpm_levels[] past [16]) of up to ~4B iterations on a Vega20 system when MCLK switching is disabled before the latency table is populated — a DoS (hang/panic from OOB read or page fault) and potential info leak. On this guest: **not reachable** (no AMD GPU).