CVE-2026-23468 Overview
A resource exhaustion vulnerability has been identified in the Linux kernel's AMDGPU driver. The vulnerability exists in the buffer object (BO) list handling mechanism, where userspace applications can pass an arbitrary number of BO list entries via the bo_number field. While previous multiplication overflow checks prevent out-of-bounds allocation, a malicious actor could still cause excessive memory allocation (potentially gigabytes) and unnecessarily long list processing times, leading to denial of service conditions.
Critical Impact
Unprivileged local attackers can cause system-wide memory exhaustion and denial of service by submitting crafted AMDGPU ioctl requests with excessive buffer object list entries.
Affected Products
- Linux kernel with AMDGPU DRM driver enabled
- Systems with AMD GPU hardware utilizing the amdgpu kernel module
Discovery Timeline
- 2026-04-03 - CVE CVE-2026-23468 published to NVD
- 2026-04-07 - Last updated in NVD database
Technical Details for CVE-2026-23468
Vulnerability Analysis
The vulnerability resides in the AMDGPU Direct Rendering Manager (DRM) subsystem within the Linux kernel. The DRM subsystem handles communication between userspace graphics applications and GPU hardware. In this case, the buffer object list processing code accepts user-controlled input specifying the number of entries to process without enforcing reasonable limits.
When a userspace application submits a GPU command through the AMDGPU driver, it can specify buffer objects that need to be mapped for the operation. The bo_number field indicates how many buffer object entries are included in the request. Although the code already contained a multiplication overflow check to prevent integer overflow attacks, there was no upper bound validation on the entry count itself.
An attacker with local access could craft malicious ioctl requests specifying extremely large buffer object counts (e.g., millions of entries), forcing the kernel to allocate substantial memory to accommodate the list and spend excessive CPU cycles processing it. This leads to memory exhaustion and system unresponsiveness.
Root Cause
The root cause is missing input validation on the bo_number field in the AMDGPU ioctl handler. While the code defended against multiplication overflow, it failed to implement a reasonable upper bound on the number of buffer object entries a single request could contain. This allowed attackers to trigger excessive memory allocation through legitimate kernel interfaces.
Attack Vector
The attack can be executed by any local user with access to the GPU device node (typically /dev/dri/card* or /dev/dri/renderD*). The attacker crafts an ioctl request to the AMDGPU driver with the bo_number field set to an extremely large value. When the kernel processes this request, it attempts to allocate memory proportional to the requested entry count, potentially consuming all available system memory.
The fix introduces a hard limit of 128,000 entries per BO list, which is more than sufficient for legitimate use cases while preventing abuse. Requests exceeding this limit now return -EINVAL (invalid argument).
Detection Methods for CVE-2026-23468
Indicators of Compromise
- Unusual memory pressure or out-of-memory (OOM) killer activity on systems with AMD GPUs
- High memory consumption by kernel threads handling AMDGPU operations
- System unresponsiveness or slowdown on GPU-equipped systems
- Repeated failed ioctl calls to AMDGPU device nodes with large bo_number values
Detection Strategies
- Monitor kernel logs for OOM killer invocations and memory allocation failures in the DRM/AMDGPU subsystem
- Implement system call auditing for ioctl calls to DRM device nodes with anomalous parameters
- Track memory allocation patterns in the kernel's DRM subsystem using kernel tracing tools like ftrace or eBPF
- Configure alerts for excessive memory consumption by processes interacting with GPU devices
Monitoring Recommendations
- Enable kernel memory allocation tracing for the amdgpu module using dynamic debug
- Monitor /proc/meminfo and /sys/kernel/slab/ for unusual allocation patterns in DRM-related caches
- Use SentinelOne's Singularity platform to detect anomalous system resource consumption patterns
- Implement process-level monitoring for applications making excessive GPU-related system calls
How to Mitigate CVE-2026-23468
Immediate Actions Required
- Update the Linux kernel to a patched version containing commit 688b87d39e0aa8135105b40dc167d74b5ada5332 or its cherry-picks
- Restrict access to GPU device nodes (/dev/dri/*) to trusted users and groups only
- Monitor systems for unusual memory consumption patterns until patches can be applied
- Consider temporarily disabling the amdgpu driver on non-essential systems if patches are not immediately available
Patch Information
The vulnerability has been resolved through kernel patches that introduce a hard limit of 128,000 entries per buffer object list. The fix returns -EINVAL if the requested entry count exceeds this limit. Patches are available through the stable kernel Git repositories:
The original fix was cherry-picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332.
Workarounds
- Limit GPU device node access using file permissions: chmod 660 /dev/dri/render* and restrict group membership
- Implement resource limits (ulimits) for processes interacting with GPU devices to cap memory consumption
- Use cgroups to isolate GPU-using applications and limit their memory allocation capabilities
- Deploy SentinelOne's runtime protection to detect and block anomalous resource consumption patterns
# Restrict GPU device access to specific group
chmod 660 /dev/dri/renderD*
chgrp video /dev/dri/renderD*
# Verify current kernel version
uname -r
# Check if amdgpu module is loaded
lsmod | grep amdgpu
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
