LACT: polkit authorization keyed on peer PID lets a local user bypass authentication to the GPU control daemon

CVE-2026-75037NVIDIA / GPU stackcurated

Impact

LACT's privileged daemon authorizes callers using a polkit UnixProcessSubject built from the peer's PID. PID-based subjects are racy by construction - a local user can get a request attributed to a different, already-authorized process - so an unprivileged local account can reach privileged daemon operations without authenticating. LACT's job is changing AMD GPU clocks, power limits, voltage and fan curves, which means the practical result on a shared AMD GPU host is a local user who can throttle, overclock or thermally mis-tune cards other tenants are running on, and who holds a foothold in a root-owned daemon. This only matters where LACT is actually installed - it is a tuning tool, not part of ROCm, so most fleets will not have it. Where an operator did install it to set power caps, it is a local privilege boundary that is not holding.

Who can reach it

A local unprivileged user on the host who can talk to the LACT daemon's D-Bus/socket interface. No authentication is needed - that is the bug. Not reachable over the network, and not reachable from a container that does not expose the daemon's socket.

What to do

Update to a LACT build containing commit d0478fe42c2219454e272f96b1cbd29ab37ee566 - versions through 0.10.0 are affected and the record names no fixed release number - then restart the lactd service. If you only used LACT for one-time power-limit tuning, the cheaper move is to remove or mask the daemon on shared nodes and set power caps with rocm-smi/amdgpu sysfs from your config management instead. Either way this is a service restart, not a node drain.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-75037 https://bugzilla.suse.com/show_bug.cgi?id=1276480 https://github.com/ilya-zlobintsev/LACT

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.