Description

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix pptable use-after-free amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:49.593Z",
  "pubdate": "2026-08-15T13:17:49.593Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel within the AMDGPU power management component, specifically affecting the power table (pptable) retrieval interface exposed via sysfs.\nThe vulnerability arises when the amdgpu_dpm_get_pp_table() function returns a direct pointer to driver-owned memory after releasing the governing mutex lock (adev->pm.mutex).\nAn unprivileged local attacker or concurrent process capable of issuing a sysfs pp_table write operation can trigger the reallocation or freeing of the underlying power table memory allocation while a read operation is simultaneously copying from that same pointer.\nSuccessful exploitation of this flaw can lead to kernel memory corruption, unexpected system crashes (kernel panic), or potentially arbitrary code execution within kernel space, posing significant risks to system stability and local security.\nThe attack requires local access to the system and the ability to interact with the sysfs filesystem exposed by the amdgpu driver, with exploitation contingent upon a race condition between concurrent sysfs read and write operations targeting the power table attribute.",
  "technicalDetails": "The vulnerability resides in the AMDGPU power management driver interface within the Linux kernel, specifically involving the handling of power tables (pptables) accessed via sysfs attributes.\nThe root cause is a synchronization flaw and improper lifetime management of driver-owned internal memory allocations. Historically, the function amdgpu_dpm_get_pp_table() acquired the adev->pm.mutex lock to safely retrieve a pointer to the internal power table structure, but subsequently dropped the mutex before returning the raw pointer to the caller.\nThe sysfs subsystem read handler then proceeded to copy data from the returned driver-owned pointer without holding the necessary locking primitives. Because the mutex was released, a concurrent sysfs write operation targeting the pp_table attribute could invoke routines that replace, reallocate, or free the existing power table memory structure while the read operation was still actively dereferencing the original pointer.\nThis creates a classic Time-of-Check to Time-of-Use (TOCTOU) race condition leading directly to a use-after-free (UAF) condition.\nThe attack flow proceeds as follows: First, an attacker initiates a read request on the vulnerable amdgpu sysfs power table attribute. The kernel executes amdgpu_dpm_get_pp_table(), retrieves the internal pointer, and drops the adev->pm.mutex lock. Second, the attacker or a concurrent thread immediately triggers a write operation to the same pp_table sysfs attribute, causing the kernel to free the original power table allocation and assign a new memory block or deallocate it entirely. Third, the initial read operation resumes copying from the stale, dangling pointer, accessing freed memory.\nThe impact of this behavior includes kernel memory corruption, denial of service via kernel crashes, and potential local privilege escalation depending on kernel heap layout and exploitation reliability.\nPrivilege and authentication requirements are limited to local system access with permissions to interact with the device's sysfs interface. No network exposure is involved as the vulnerability is strictly local to the kernel driver interface."
}