# DF-4249 — Extended-header fields read before/without `usSize` gate

## Where
`sys/dev/drm/amd/powerplay/hwmgr/processpptables.c`
1. `init_dpm2_parameters` :1488 — reads `extended_header->usPPMTableOffset`
   (byte offset +16..17 of the extended header) **before** checking
   `usSize >= SIZE_OF_ATOM_PPLIB_EXTENDEDHEADER_V5` (:1489-1490). A VBIOS
   whose extended header is only V2-sized (12 bytes) still has the field read.
2. `init_overdrive_limits_V2_1` :1029-1033 — reads
   `header->ulMaxEngineClock` / `ulMaxMemoryClock` (+8..15) with **no**
   `usSize` gate at all, unlike every sibling getter (e.g. get_vce_table_offset
   gates on `usSize >= V2`).

## What
Both are within-image OOB reads past the firmware-declared end of the
extended-header sub-table: the parser honors `usSize` for *gating* but reads
fields located past it first. Values land in `hwmgr->platform_descriptor`
(overdrive limits) or select a PPM table offset — no direct leak to
userspace, but the PPM offset then indexes the image and (unpatched) feeds
the unvalidated-offset family (DF-1470).

## Trigger
Crafted VBIOS / pp_table with `usExtendendedHeaderOffset != 0` and a short
`usSize`. Hardware-gated (AMD ASIC required).

## Fix
Contained in DF-4247/fix.diff:
* PPM: reorder so `usSize >= V5` is tested before `usPPMTableOffset` is read,
  plus a `pp_table_range_ok` check on the PPM table itself.
* V2_1: gate the header deref on `usSize >= V3` footprint via
  `pp_table_range_ok`.

## Build/run
Hardware-gated; run.sh documents absence of AMD hardware.
