CVE-2026-90136: platform/x86/amd/hsmp: Reject negative power cap writes in hwmon
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/hsmp: Reject negative power cap writes in hwmon
hsmphwmonwrite() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATTPERMILLIWATT" to msg.args[0], which is a u32. MICROWATTPERMILLIWATT is an unsigned long, so a negative write to power1cap (e.g. "echo -1 > power1cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument.
As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMPSETSOCKETPOWERLIMIT instead of the write being rejected.
Reject negative values with -EINVAL before the conversion.
Tested with HSMP enabled:
CAP=$(dirname $(grep -l amdhsmphwmon \ /sys/class/hwmon/hwmon/name | head -1))/power1cap
# negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?"
Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0
After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Linux kernel HSMP hwmon implementation to reject negative writes to the socket power cap (e.g., power1_cap) by returning -EINVAL before converting the signed user-supplied value. This prevents nonsensical multi-gigawatt limits caused by treating negative values as unsigned after division by MICROWATT_PER_MILLIWATT.
platform/x86/amd/hsmp hwmon power cap write (hwmon*/power1_cap) Reject negative power cap writes with -EINVAL = -EINVAL
Event History
Frequently Asked Questions
Which systems are exposed to this behavior?
Systems with AMD HSMP enabled and an amd_hsmp_hwmon hwmon device exposing the power1_cap attribute are affected by the vulnerable behavior.
What access is required to trigger the issue?
An actor must be able to write a negative value to the power1_cap hwmon attribute. A negative value is converted and sent through HSMP_SET_SOCKET_POWER_LIMIT as a nonsensical multi-gigawatt socket power limit.
How can I determine whether the fix is present?
On an affected HSMP-enabled system, writing a negative value such as -1000000 to the relevant power1_cap file succeeds before the fix. With the fix, the write fails with an Invalid argument error (-EINVAL).
Will the change prevent legitimate power-cap configuration?
No. Positive power-cap writes remain accepted; the provided test shows a write of 400000000 succeeding after negative values are rejected.