• File: sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
• Lines: 428–440 (entries[0]), 784 (off-by-one)
• Severity: Low
• CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H
• CWE: CWE-193 Off-by-One Error
• Confidence: likely

Summary

Two small but real defects in array-walk preconditions.

1. get_clock_voltage_limit unconditionally indexes table->entries[0] without verifying that table->ucNumEntries >= 1; a VBIOS limit table with numEntries=0 reads one record past the table header.

2. get_state_entry_v2 uses entry_index <= ucNumEntries (processpptables.c:784), allowing the caller's permissive entry_index > ucNumEntries check (processpptables.c:913) to pass entry_index == ucNumEntries, which walks one state past the last and returns a pointer that the caller then dereferences.

Root cause

1. get_clock_voltage_limit, processpptables.c:428-440: limits->sclk = ... le16_to_cpu(table->entries[0].usSclkLow); etc. — entries[0] is taken with no table->ucNumEntries >= 1 precondition. The function is reached from init_clock_voltage_dependency at processpptables.c:1328-1334 only when usMaxClockVoltageOnDCOffset != 0, so a VBIOS that points that offset at a 0-entry limit table triggers the OOB read.

2. get_state_entry_v2, processpptables.c:784: the test should be <, not <=. Combined with the caller's permissive test at processpptables.c:913 (entry_index > ucNumEntries), an entry_index equal to ucNumEntries causes the for-loop at processpptables.c:785-788 to advance ucNumEntries times — leaving pstate pointing past the final state — and the caller dereferences it at processpptables.c:916, 923-935.

The normal caller loop (i = 0..num_entries-1) does not hit this, so the bug is latent unless a future caller relies on the documented entry-count contract.

Threat

Local, same VBIOS-controlled precondition.

Path (1) is directly reachable from a crafted VBIOS at driver init and yields a small OOB read (one ATOM_PPLIB_Clock_Voltage_Limit_Record past the table header), likely info-leak or panic depending on adjacent mapping.

Path (2) is currently unreachable through the only existing caller but is a textbook latent off-by-one waiting on a future caller change.

Exploit / PoC

Path (1): point POWERPLAYTABLE4.usMaxClockVoltageOnDCOffset at an ATOM_PPLIB_Clock_Voltage_Limit_Table with ucNumEntries = 0; on driver attach, get_clock_voltage_limit reads 12 bytes past the table header at processpptables.c:432-437.

Observable: garbage values in dyn_state.max_clock_voltage_on_dc or a fault if the next page is unmapped.

Path (2) is a defensive fix; no live repro through current callers.

Recommended fix

--- a/sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/sys/dev/drm/amd/powerplay/hwmgr/processpptables.c
@@ -428,6 +428,9 @@ static int get_clock_voltage_limit(struct pp_hwmgr *hwmgr,
            struct phm_clock_and_voltage_limits *limits,
            const ATOM_PPLIB_Clock_Voltage_Limit_Table *table)
 {
+   if (table->ucNumEntries < 1)
+       return -EINVAL;
+
    limits->sclk = ((unsigned long)table->entries[0].ucSclkHigh << 16) |
            le16_to_cpu(table->entries[0].usSclkLow);
@@ -784,3 +787,3 @@ static const ATOM_PPLIB_STATE_V2 *get_state_entry_v2(
    pstate = pstate_arrays->states;
-   if (entry_index <= pstate_arrays->ucNumEntries) {
+   if (entry_index < pstate_arrays->ucNumEntries) {
        for (i = 0; i < entry_index; i++)

Also tighten the caller's guard at processpptables.c:913 and :937 from entry_index > ...ucNumEntries to entry_index >= ...ucNumEntries for defense-in-depth.

Related findings

• DF-1468/1469/1470/1471: same file's VBIOS parsing OOB family.