CVE-2024-26949 - Understanding and Exploiting the Linux Kernel amdgpu Power Limit Dereference Bug
On February 2024, CVE-2024-26949 was discovered in the Linux kernel, specifically within the AMD GPU (amdgpu) driver’s power management subsystem. This vulnerability could expose systems to a NULL pointer dereference, potentially leading to system crashes or denial of service. In this post, I’ll explain what happened, how it was fixed, and how the bug can be triggered—with sample code and useful references to get started.
What is CVE-2024-26949?
CVE-2024-26949 is a vulnerability found in the Linux kernel’s amdgpu/pm (power management) code. In certain cases—especially when SR-IOV (Single Root I/O Virtualization) is active—the powerplay_table does not get properly initialized. Some kernel code later assumes it’s ready and tries to use it, leading to a NULL pointer dereference if it’s not set.
In virtualization scenarios like SR-IOV, the powerplay_table might not be set up.
- Functions trying to access the device’s power limits directly read values from the powerplay_table without checking whether it is NULL.
- If an attacker or a user-space program triggers this code path, the kernel dereferences a NULL pointer and, in most cases, crashes.
Upstream Fix
The Linux kernel patch for CVE-2024-26949 adds a NULL check before accessing the table, plus falls back to default safe values if the table is missing:
> Because powerplay_table initialization is skipped under sriov case,
> We check and set default lower and upper OD value if powerplay_table is NULL.
Source:
- LKML Commit: drm/amdgpu/pm: Fix NULL pointer dereference when get power limit
- CVE Record
Technical Details
Let’s look at the vulnerable code. The power limit querying code looks like this before the patch (simplified):
int amdgpu_pm_get_power_limit(struct amdgpu_device *adev) {
// Assume powerplay_table exists
return adev->powerplay_table->power_limit;
}
If adev->powerplay_table is NULL, accessing ->power_limit causes a kernel OOPS.
After the patch
int amdgpu_pm_get_power_limit(struct amdgpu_device *adev) {
if (!adev->powerplay_table) {
// Return a safe fallback value
return DEFAULT_POWER_LIMIT;
}
return adev->powerplay_table->power_limit;
}
The system needs to use an AMD GPU with SR-IOV enabled.
- A user space process (local attacker) triggers the power management ioctl or sysfs call at the wrong moment.
- With default settings, an unprivileged process probably cannot hit this bug unless root, or unless system setup enables certain device access.
Suppose you have direct access to the affected sysfs/power interface
cat /sys/class/drm/card/device/hwmon/hwmon*/power1_cap
Or via ioctl (pseudo-code)
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
int fd = open("/dev/dri/card", O_RDWR);
if (fd < ) return 1;
// Replace with real IOCTL value; pseudo example:
#define DRM_IOCTL_AMDGPU_GET_POWER_LIMIT x1234
int power_limit;
ioctl(fd, DRM_IOCTL_AMDGPU_GET_POWER_LIMIT, &power_limit);
If the SR-IOV case skips setting the powerplay table, the driver tries to read from NULL, causing a kernel panic.
Risk: System crash, loss of availability—not privilege escalation or data breach.
- Systems Affected: Linux with AMD GPUs where SR-IOV is used (cloud, virtualization, GPU passthrough).
How To Patch
Are you affected?
If your system does not use SR-IOV or AMD GPUs, you are likely safe.
How to fix:
- Upgrade to a Linux kernel version containing the patch (mainline after Feb 21, 2024, or your distro’s patched kernel).
- Check status on kernel.org
References
- NVD - CVE-2024-26949
- Upstream Kernel Patch
- SR-IOV Documentation
- amdgpu Power Management Docs
Conclusion
CVE-2024-26949 is a straightforward but impactful kernel bug: an unchecked pointer in a driver, exposed to the surface by advanced virtualization setups. The simple fix is a NULL check and a safe fallback, but until patched, the bug remains a low-effort avenue for a local system crash in vulnerable configurations. Patch your kernel or apply the upstream fix to keep your systems reliable.
Timeline
Published on: 05/01/2024 06:15:10 UTC
Last modified on: 05/29/2024 05:25:42 UTC