Summary
The cpu_*_powerlimit sysfs attributes route through two different store paths depending on the per-model access_method_powerlimits setting, and only one of them clamps the user-supplied value:
ACCESS_METHOD_WMI3_CLAMPED -> wmi_clamped_store() -> clamped_value() -> capdata_clamp() clamps against the firmware capability table.ACCESS_METHOD_WMI3 -> wmi_common_method_other_store() passes the raw kstrtoint value straight to the WMI method (wmi_other_method_set_value(), which contains no validation).
Affected: cpu_shortterm_powerlimit (legion-laptop.c:6198), cpu_longterm_powerlimit (:6271), cpu_peak_powerlimit (:6341), cpu_apu_sppt_powerlimit (:6375).
A second, defense-in-depth gap in the same area: capdata_clamp() (legion-laptop.c:2796) returns the raw unclamped value when no matching capdata01 entry is found for the current powermode (if (!cd) return value;). So even the "clamped" path silently degrades to unclamped whenever capdata is incomplete for a model/powermode.
Questions
- Is the raw pass-through on
ACCESS_METHOD_WMI3 intentional (e.g. those firmwares enforce their own limits and capdata is unreliable for them)? If so, a comment would prevent "fixing" it later.
- For
WMI3_CLAMPED: when capdata_clamp finds no entry, should the store be rejected (-EINVAL) instead of passing the value through? That would make the failure loud rather than silently writing an arbitrary value to firmware.
Neither is an active bug I could demonstrate (no hardware access here) — flagging as defensive-hardening candidates that need firmware testing before any change.
Summary
The
cpu_*_powerlimitsysfs attributes route through two different store paths depending on the per-modelaccess_method_powerlimitssetting, and only one of them clamps the user-supplied value:ACCESS_METHOD_WMI3_CLAMPED->wmi_clamped_store()->clamped_value()->capdata_clamp()clamps against the firmware capability table.ACCESS_METHOD_WMI3->wmi_common_method_other_store()passes the raw kstrtoint value straight to the WMI method (wmi_other_method_set_value(), which contains no validation).Affected:
cpu_shortterm_powerlimit(legion-laptop.c:6198),cpu_longterm_powerlimit(:6271),cpu_peak_powerlimit(:6341),cpu_apu_sppt_powerlimit(:6375).A second, defense-in-depth gap in the same area:
capdata_clamp()(legion-laptop.c:2796) returns the raw unclamped value when no matchingcapdata01entry is found for the current powermode (if (!cd) return value;). So even the "clamped" path silently degrades to unclamped whenever capdata is incomplete for a model/powermode.Questions
ACCESS_METHOD_WMI3intentional (e.g. those firmwares enforce their own limits and capdata is unreliable for them)? If so, a comment would prevent "fixing" it later.WMI3_CLAMPED: whencapdata_clampfinds no entry, should the store be rejected (-EINVAL) instead of passing the value through? That would make the failure loud rather than silently writing an arbitrary value to firmware.Neither is an active bug I could demonstrate (no hardware access here) — flagging as defensive-hardening candidates that need firmware testing before any change.