• File: sys/dev/drm/amd/display/dc/calcs/dcn_calcs.c
• Lines: 1368, 1370, 1371, 1373, 1374
• Severity: Low
• CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
• CWE: CWE-125 Out-of-bounds Read
• Confidence: likely

Summary

dcn_bw_update_from_pplib() indexes fclks.data[] with num_levels-2 (and a num_levels-2/num_levels-3 ternary) after only checking that num_levels is non-zero (via verify_clock_values) and after an ASSERT(num_levels>=3) that is compiled to non-fatal WARN_ON in production.

If dm_pp_get_clock_levels_by_type_with_voltage() returns num_levels==1, the expressions fclks.data[num_levels-2] and fclks.data[num_levels-(num_levels>2?3:2)] evaluate to data[-1], reading 8 bytes immediately before the fclks struct on the kernel stack.

Root cause

verify_clock_values (dcn_calcs.c:1337-1350) returns false only when num_levels==0 or any clocks_in_khz==0; it does NOT enforce a minimum of 2 or 3 levels.

In dcn_bw_update_from_pplib (dcn_calcs.c:1367-1378), after if (res) (which only guarantees num_levels>=1), the code does:

ASSERT(fclks.num_levels >= 3);  /* 1368 — WARN_ON in production, no gate */
... (fclks.data[fclks.num_levels - (fclks.num_levels > 2 ? 3 : 2)].clocks_in_khz / 1000.0) ...
... fclks.data[fclks.num_levels - 2].clocks_in_khz ...

With num_levels==1, num_levels - 2 == -1 and num_levels - (num_levels>2?3:2) == 1-2 == -1, so both accesses read fclks.data[-1].

struct dm_pp_clock_levels_with_voltage (dm_services_types.h:109-112) places data[8] at offset 4 (after uint32_t num_levels); data[-1] resolves to offset 4 - sizeof(dm_pp_clock_with_voltage) = 4-8 = -4, i.e. 4 bytes before the struct plus the num_levels field itself — an out-of-bounds read of adjacent kernel stack.

Contrast with the dcfclks path at lines 1388–1392 which IS correctly guarded by if (res && dcfclks.num_levels >= 3).

Threat

Requires an AMD DCN1 APU whose powerplay/SMU firmware (or the linuxkpi DM wrapper around it, amdgpu_dm_pp_smu.c:391) reports exactly one non-zero FCLK DPM level via dm_pp_get_clock_levels_by_type_with_voltage(DM_PP_CLOCK_TYPE_FCLK).

This is a degenerate but possible firmware/ASIC state, especially on early Raven ridges or embedded parts with fused DPM tables, or when the powerplay layer is only partially functional.

Reachability is from kernel-side display init/hotplug (dcn_bw_update_from_pplib is called by the DC on clock-state sync), not directly from an unprivileged syscall; the attacker would need to be in a position to trigger a display reprobe/resync on affected hardware.

Impact: 4-8 bytes of adjacent kernel stack are read, multiplied into the dcn_soc fabric_and_dram_bandwidth_vmid0p72/vnom0p8 floats, and later reflected through DC_LOG_BANDWIDTH_CALCS (dcn_calcs.c:1486) — a minor kernel info leak into a logged value, plus corruption of bandwidth programming that could destabilise the display (DoS-adjacent).

Not a code-execution primitive.

Exploit / PoC

This is hardware/firmware-state dependent rather than directly attacker-controlled.

The reproducible proof is a KLD test harness on a DCN1 box (or an emulated DM layer) that injects a dm_pp_clock_levels_with_voltage with num_levels=1 and a single non-zero clocks_in_khz entry and then invokes dcn_bw_update_from_pplib(dc).

Observe via KASAN/UMR or by instrumenting the returned dcn_soc values that fabric_and_dram_bandwidth_vmid0p72/vnom0p8 take on garbage derived from stack bytes preceding the fclks local.

Sample harness (drop into findings/poc/DF-1486/harness.c, built as a FreeBSD-style KLD module against the DC symbols):

struct dm_pp_clock_levels_with_voltage f = {
    .num_levels = 1,
    .data[0] = { .clocks_in_khz = 960000, .voltage_in_mv = 800 }
};
/* stub dm_pp_get_clock_levels_by_type_with_voltage to copy f into the
 * out-param for DM_PP_CLOCK_TYPE_FCLK and return true; */
dcn_bw_update_from_pplib(dc);
/* read back dc->dcn_soc->fabric_and_dram_bandwidth_vmid0p72 — observe a
 * non-deterministic value correlated with whatever lived on the stack above
 * fclks. */

Success criterion: KASAN reports a stack-out-of-bounds read at dcn_calcs.c:1371/1374, or the bandwidth value varies run-to-run independently of the injected clock.

Recommended fix

Promote the ASSERT to a real bounds check, mirroring the existing dcfclks guard, and fall back to the SOC defaults when the firmware table is degenerate.

--- a/sys/dev/drm/amd/display/dc/calcs/dcn_calcs.c
+++ b/sys/dev/drm/amd/display/dc/calcs/dcn_calcs.c
@@ -1365,10 +1365,16 @@ void dcn_bw_update_from_pplib(struct dc *dc)
    if (res)
        res = verify_clock_values(&fclks);

-   if (res) {
-       ASSERT(fclks.num_levels >= 3);
+   if (res && fclks.num_levels >= 3) {
        dc->dcn_soc->fabric_and_dram_bandwidth_vmin0p65 = 32 * (fclks.data[0].clocks_in_khz / 1000.0) / 1000.0;
-       dc->dcn_soc->fabric_and_dram_bandwidth_vmid0p72 = dc->dcn_soc->number_of_channels *
+       dc->dcn_soc->fabric_and_dram_bandwidth_vmid0p72 =
+               dc->dcn_soc->number_of_channels *
            (fclks.data[fclks.num_levels - (fclks.num_levels > 2 ? 3 : 2)].clocks_in_khz / 1000.0)
            * ddr4_dram_factor_single_Channel / 1000.0;
        dc->dcn_soc->fabric_and_dram_bandwidth_vnom0p8 = dc->dcn_soc->number_of_channels *
@@ -1378,7 +1384,7 @@ void dcn_bw_update_from_pplib(struct dc *dc)
            (fclks.data[fclks.num_levels - 1].clocks_in_khz / 1000.0)
            * ddr4_dram_factor_single_Channel / 1000.0;
    } else
-       BREAK_TO_DEBUGGER();
+       BREAK_TO_DEBUGGER(); /* keep SOC defaults on degenerate firmware tables */

Related findings

• DF-1485 (sibling): NULL-pipe deref in same file.