DF-4290 — SS getters emit success with speed_spectrum_rate == 0 → integer divide-by-zero panic in clock-spread callers

Pass-2 finding for sys/dev/drm/amd/powerplay/hwmgr/ppatomctrl.c (the "(c) rate==0 div0 family" hinted by the pass-2 brief).

The bug

asic_internal_ss_get_ss_asignment() copies the raw VBIOS rate into the caller-visible struct and returns success without validating it (ppatomctrl.c:1245-1254):

if (entry_found) {
        ssEntry->speed_spectrum_percentage =
                le16_to_cpu(ssInfo->usSpreadSpectrumPercentage);
        ssEntry->speed_spectrum_rate = le16_to_cpu(ssInfo->usSpreadRateInKhz);   // :1248

        if (((GET_DATA_TABLE_MAJOR_REVISION(table) == 2) &&
            (GET_DATA_TABLE_MINOR_REVISION(table) >= 2)) ||
            (GET_DATA_TABLE_MAJOR_REVISION(table) == 3)) {
                ssEntry->speed_spectrum_rate /= 100;                             // :1253
        }
        ...
}
return entry_found ? 0 : 1;

• A VBIOS usSpreadRateInKhz == 0 stays 0.
• For table revision ≥ 2.2 or 3, any value < 100 truncates to 0 (/= integer division) — e.g. a legal-looking 30 kHz rate becomes 0.

The unvalidated value is then used as a divisor by every consumer:

(None of the callers checks for zero; the getter's return 0 is taken as "values are usable".)

Trigger: crafted VBIOS on a CI/Bonaire/Hawaii (ci), Topaz/Volcanic (iceland), Fiji (or Tonga/VegaM analogues) dGPU that (1) sets the PHM_PlatformCaps_{Engine,Memory}SpreadSpectrumSupport cap, (2) provides an ASIC_InternalSS_Info entry matching the target clock with usSpreadRateInKhz == 0 (or < 100 on rev≥2.2 tables). Result: integer divide-by-zero in kernel → Fatal trap 0: divide error panic during SMC table construction at driver attach (CWE-369).

Reproduce

Not runnable on this audit guest (no AMD dGPU — env.txt). On hardware the trigger is purely VBIOS content; expected Fatal trap 0: divide error faulting in ci_program_display_gap/ci_populate_smc_* clock-spread setup paths.

DF-4290 VERDICT — SS rate==0 divide-by-zero

Status: inconclusive (code-trace certain; guest has no AMD dGPU)

Trace

1. Producer: asic_internal_ss_get_ss_asignment() ppatomctrl.c:1245-1254. - :1248 ssEntry->speed_spectrum_rate = le16_to_cpu(ssInfo->usSpreadRateInKhz); — raw USHORT from the VBIOS table, no zero check. - :1250-1254 for GET_DATA_TABLE_MAJOR_REVISION==2 && minor>=2 or major==3: ssEntry->speed_spectrum_rate /= 100; — integer division; values 0..99 collapse to 0. (GET_DATA_TABLE_*_REVISION read table->sHeader — same header whose usStructureSize is unvalidated, see DF-4289; the revision bytes are likewise VBIOS-controlled.) - :1272 return entry_found ? 0 : 1; — success.
2. Consumers (all reached from *_populate_* SMC-table construction at driver attach, gated only on the VBIOS-provided PHM_PlatformCaps_*SpreadSpectrumSupport caps): - ci_smumgr.c:338-356 — if (!atomctrl_get_engine_clock_spread_spectrum(...)) then :345 clk_s = ref_clock * 5 / (ref_divider * ss_info.speed_spectrum_rate); → DIV by 0 when rate==0 and ref_divider!=0 (ref_divider=1 typical); the product ref_divider * rate is a u32 multiply, 0 either factor ⇒ divide error (#DE) → kernel panic. - ci_smumgr.c:1084-1088 — memory-clock variant, same shape at :1085. - iceland_smumgr.c:843-859 — same at :849. - iceland_smumgr.c:1125-1135 family — same shape at :1131. - fiji_smumgr.c:909-915 — same at :914. - tonga/vegam equivalents exist for their SS-capable SKUs.
3. No consumer checks speed_spectrum_rate != 0 before dividing; the getter returning 0 (success) is treated as a green light.
4. x86-64 kernel #DE → Fatal trap 0: divide error → panic during kldload/attach (non-recoverable; attach holds device locks).

Why the finding is filed against ppatomctrl.c

The zero value is manufactured in this file (:1248 raw copy, :1253 truncating division); the single-point fix is to fail the lookup when the rate is not usable, which neutralizes every downstream division at once. (Callers adding their own guards is defense-in-depth.)

Impact

Crafted-VBIOS boot/module-load kernel panic (CWE-369). Medium — same threat band as DF-1497 (NULL-deref panic from VBIOS content). Not runnable on this guest (no AMD dGPU) ⇒ inconclusive status, trace-certain.

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.