UBUNTU-CVE-2026-99150: Medium severity vulnerability
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: don't drop the runtime PM reference twice in amdgpugpr amdgpudebugfsgprread() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtimeusage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copytouser() instead of the putuser() loop with its own error path. (cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a)
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel amdgputo a version that resolves this vulnerability.Patch 31035bbd74f7c3e10c163db875b8e67f8b50ee6a
Event History
Frequently Asked Questions
What condition is required to trigger the runtime PM reference error?
The issue is triggered when amdgpu_debugfs_gpr_read() copies wave-register data to an invalid userspace buffer and the copy fails after the function has already released its runtime PM reference.
Which systems are most directly implicated by the available information?
The report specifically identifies Navi31 as exhibiting either loss of another holder's runtime PM reference or a runtime PM usage-count underflow. It affects the amdgpu debugfs GPR read path in the Linux kernel.
How can an affected system be recognized?
A kernel log may contain a message such as "Runtime PM usage count underflow!" for the amdgpu PCI device after a failed debugfs GPR read. The described behavior can also reduce power/runtime_usage from 1 to 0 by consuming a reference held elsewhere.