DF-3939 — Kernel stack OOB write in ci_program_memory_timing_parameters (CI/SMU7 ARB timing table)

Finding

sys/dev/drm/amd/powerplay/smumgr/ci_smumgr.c:1648-1681

static int ci_program_memory_timing_parameters(struct pp_hwmgr *hwmgr)
{
    ...
    SMU7_Discrete_MCArbDramTimingTable  arb_regs;          /* 576-byte STACK object */
    ...
    for (i = 0; i < data->dpm_table.sclk_table.count; i++) {
        for (j = 0; j < data->dpm_table.mclk_table.count; j++) {
            result = ci_populate_memory_timing_parameters
                (hwmgr, ..., &arb_regs.entries[i][j]);

arb_regs.entries is [SMU__NUM_SCLK_DPM_STATE=8][SMU__NUM_MCLK_DPM_LEVELS=6] (sys/dev/drm/amd/powerplay/inc/smu7_discrete.h:233-236, CI constants from sys/dev/drm/amd/powerplay/smumgr/ci_smumgr.h:26-27). The loop bounds come from the VBIOS-parsed DPM table counts (dpm_table->sclk_table.count, dpm_table->mclk_table.count), which for MCLK can legitimately reach MAX_REGULAR_DPM_NUMBER = 8 (sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.h:95, smu7_hwmgr.h:100) — nothing trims them to the SMC table's 6 (smu7_setup_dpm_tables_v0, sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:704-710, copies the VBIOS ucNumEntries-sized dependency table (processpptables.c:391) into dpm_levels[8] with no SMU7_MAX_LEVELS_MEMORY clamp).

Trigger

Crafted VBIOS powerplay table on a Bonaire/Hawaii (AMDGPU_FAMILY_CI) GPU with vdd_dep_on_mclk containing >= 7 distinct MCLK entries (and, to push the write past the end of the whole stack object, 8 distinct SCLK entries so the outer loop reaches row i=7):

• mclk count 7-8 ⇒ j ∈ {6,7}:
• rows i<7: writes alias into entries[i+1][0..1] — in-object but wrong cells (corrupt SMC timing data — logic corruption);
• row i=7: entries[7][6] at byte offset 772+612 = 576 = exactly past the 576-byte object, and entries[7][7] at +588..599 — ~24 bytes past the stack object, values McArbDramTiming / McArbDramTiming2 (u32 MMIO reads of MC_ARB_DRAM_TIMING{,2} computed by the VBIOS atomctrl_set_engine_dram_timings_rv770 from the attacker's chosen engine/memory clocks) plus McArbBurstTime (u8).

Called at DPM init: ci_init_smc_table → ci_program_memory_timing_parameters (ci_smumgr.c:2002), and on OD updates ci_update_sclk_threshold → ci_program_mem_timing_parameters (ci_smumgr.c:2239).

Why inconclusive on this guest

Requires an AMD Sea Islands GPU plus a modified VBIOS. The audit QEMU guest has no AMD PCI device at all (env.txt: only Intel PIIX4, QEMU virtio-gpu, virtio-net/blk — no vendor 0x1002), so the path cannot execute. The struct math is source-certain: this is the CI twin of the verified tonga finding DF-3908 (tonga_smumgr.c:1492-1507, entries[8][4] vs MCLK counts up to 8).

Reproduce (on hardware)

Flash a CI board VBIOS whose ATOM powerplay vdd_dep_on_mclk table has 7-8 distinct entries (and sclk dep table with 8), boot with amdgpu dpm enabled; ci_program_memory_timing_parameters scribbles past the 576-byte stack object during ci_init_smc_table — expect corruption/panic on stack canary kernels, silent adjacent-stack corruption otherwise.

DF-3939 — VERDICT

Status: inconclusive (hardware-gated) — source-level certainty: HIGH/certain. Impact class: kernel stack out-of-bounds write (CWE-787), crafted-VBIOS vector.

Root cause (path:line)

• sys/dev/drm/amd/powerplay/smumgr/ci_smumgr.c:1653 — SMU7_Discrete_MCArbDramTimingTable arb_regs; is a stack object of entries[8][6] = 8612 = 576 bytes (sys/dev/drm/amd/powerplay/inc/smu7_discrete.h:223-236: entry = u32+u32+u8+pad3 = 12B; dims SMU__NUM_SCLK_DPM_STATE=8 x SMU__NUM_MCLK_DPM_LEVELS=6 from sys/dev/drm/amd/powerplay/smumgr/ci_smumgr.h:26-27).
• ci_smumgr.c:1658-1663 — the loop bounds are data->dpm_table.sclk_table.count and data->dpm_table.mclk_table.count, never validated against the array dims.
• Provenance of the counts (no clamp anywhere on the MCLK side):
• V0 pptable parser: sys/dev/drm/amd/powerplay/hwmgr/processpptables.c:391 — dep_table->count = table->ucNumEntries (u8, up to 255; entries dynamically allocated, hwmgr.h:120-123).
• sys/dev/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:704-710 — dedup loop writes dpm_levels[...] up to the dep-table count; dpm_levels[MAX_REGULAR_DPM_NUMBER=8] (smu7_hwmgr.h:95,98-101). Counts 7-8 fit the hwmgr arrays but exceed the SMC table's 6.
• Contrast: VDDC/VDDCI/MVDD voltage tables are trimmed to their SMC level counts (smu7_hwmgr.c:324-346 via phm_trim_voltage_table_to_fit_state_table + smum_get_mac_definition), and the PCIE table is capped with min(SMU7_MAX_LEVELS_LINK, count) plus a reserved boot slot (smu7_hwmgr.c:557-569). SCLK/MCLK level counts are the one family with no trim — for SCLK this is harmless (8 == GraphicsLevel[8]); for MCLK it is 8 > 6 = MemoryLevel/entries dim.

Overflow math

&arb_regs.entries[i][j] at byte offset i*72 + j*12:

Written values: McArbDramTiming, McArbDramTiming2 = MMIO reads of mmMC_ARB_DRAM_TIMING{,2} whose contents the VBIOS computed from the attacker-chosen engine/memory clocks (ci_populate_memory_timing_parameters, ci_smumgr.c:1619-1645); McArbBurstTime = MC_ARB_BURST_TIME.STATE0 field. Reach: both call sites — DPM init (ci_init_smc_table → ci_smumgr.c:2002) and OD/profile updates (ci_update_sclk_threshold → ci_smumgr.c:2239).

Why not reproduced

The single-tenant audit guest has no AMD GPU (env.txt — pciconf -l shows only Intel PIIX4 + virtio devices; zero vendor-0x1002 functions) and no CI hardware can be attached; the path additionally requires a modified VBIOS. Classification inconclusive mirrors the tonga twins DF-3908/DF-3909 and the batch precedent DF-3934/DF-3935. No uid=0 chain is developable without the device: the primitive (24B semi-controlled write past a 576B stack object, repeatable on every DPM re-init) would on real hardware be a strong stack corruption candidate.

Fix validation

fix.diff clamps both loops to the array dims (SMU7_MAX_LEVELS_GRAPHICS / SMU7_MAX_LEVELS_MEMORY). Not testable on this guest (no CI GPU), so fix_status: not_testable; the diff is bounds-only and matches the upstream tonga hardening pattern. The deeper fix (trim MCLK count once, in smu7_setup_dpm_tables_v0/v1, like the voltage/PCIE tables) belongs to smu7_hwmgr.c and also fixes DF-3940's sinks at the source.

Also noted (not re-reported / out of this file)

• smu7_hwmgr.c:704-710/783-799: dep-table counts > 8 overflow dpm_levels[8] in the hwmgr backend itself — separate file, flagged to the orchestrator in the batch JSON negatives.

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.