Re: [PATCH 0/2] powercap: dtpm: Fix out-of-bounds read in the set_pd_power_limit() callbacks

[Mikhail Dmitrichenko]

Hi,

On Fri, Jun 12, 2026 at 09:25:34AM +0300, Elazar Leibovich wrote:
> The powercap core clamps the requested limit to dtpm->power_min, but
> that clamp can be computed from stale data: in dtpm_cpu the number of
> online CPUs may have grown since power_min was last updated, and in
> dtpm_devfreq the EM table may have been updated at runtime via
> em_dev_update_perf_domain(). In both cases the clamped limit can still
> be below the first state's power, making the underflow reachable.

The underflow is also reachable without any race, by setting a power
limit on a non-leaf node of the DTPM hierarchy.

__set_power_limit_uw() distributes the limit of a node among its
children proportionally to their weights, and the weights are computed
from power_max only. The share of a child is not clamped to its own
power_min, so when the limit of the parent is close to its power_min,
a child whose power_min is high compared to its power_max gets a share
below the power of its lowest performance state. set_pd_power_limit()
then breaks at i == 0 and reads table[-1].

For instance, with two CPU performance domains under the same parent,
one with a 80-1200 range and the other one with a 400-3000 range, the
parent's range is 480-4200. Writing 500 to the parent's
constraint_0_power_limit_uw gives a share of about 357 to the second
domain, below its minimum of 400. The hierarchy created by
drivers/soc/rockchip/dtpm.c (the CPU clusters and the GPU under the
'package' node) has this shape. Whether a given limit triggers it
depends on the energy model values of the platform.

So this series also fixes an out-of-bounds read deterministically
reachable from sysfs, by a single write to the power limit of a parent
node.

I've posted a separate patch fixing the distribution itself, so a child
doesn't get less than its minimum power when the parent's limit allows
it [1]. It doesn't replace this series, which is still needed for the
stale power_min cases you described.

[1] https://lore.kernel.org/all/20261006151519.126065-1-mdmitrichenko@xxxxxxxxxxxxx/

Thanks,
Mikhail