A one-line fix in the Linux kernel's DRM subsystem prevents unprivileged users from exhausting system memory through the mode-setting API, addressing a potential denial-of-service vector that bypassed control group limits.
A critical memory accounting oversight in the Linux kernel's Direct Rendering Manager (DRM) graphics subsystem has been identified that could allow unprivileged users to trigger unbounded kernel memory consumption, potentially causing system-wide out-of-memory conditions.
The vulnerability exists in the DRM_IOCTL_MODE_CREATEPROPBLOB interface, which allows user-space applications to allocate arbitrary-sized property blobs for graphics configuration. This interface is commonly used by display servers and compositors to manage display properties, color management settings, and other graphics state.
The Core Problem: Missing Memory Attribution
The fundamental issue was that blob allocations through this interface weren't properly attributed to the memory control group (memcg) of the requesting process. In Linux containerized environments and systems with resource limits, memcg provides crucial isolation by tracking and limiting memory usage per process group.
When a user-space application calls DRM_IOCTL_MODE_CREATEPROPBLOB with a large size parameter, the kernel allocates memory for the blob but fails to charge it to the process's memcg. This means:
- Cgroup memory limits are bypassed
- OOM killer cannot properly identify the culprit process
- System administrators lose visibility into memory consumption
- Container escape scenarios become possible through resource exhaustion
The attack vector is straightforward: an unprivileged user process could repeatedly call this interface with progressively larger sizes, consuming kernel memory without any accounting mechanism to stop it.
The Fix: One Line, Critical Impact
Xiao Kan submitted a remarkably concise fix that addresses this vulnerability by ensuring blob allocations are properly accounted to the user process's memory control group. The patch modifies the DRM core's memory allocation path to charge the allocation to the appropriate memcg before completing the operation.
This fix has been submitted through drm-misc-next and is queued for the upcoming Linux 6.20~7.0 merge window. The drm-misc-next tree serves as a staging area for DRM subsystem improvements, and this particular change represents the most significant security fix in this week's pull request.
Technical Context and Broader Implications
This vulnerability highlights a broader pattern in kernel subsystem development: new interfaces often get added without full integration with Linux's resource management framework. The DRM subsystem has evolved rapidly to support modern graphics features, but memory accounting has lagged behind.
Similar issues have been found in other kernel areas:
- Network socket allocation accounting
- File descriptor limits bypasses
- Timer and workqueue resource tracking
The fix also demonstrates the importance of defense-in-depth. Even with proper user-space isolation and privilege separation, kernel-level resource accounting provides a critical safety net against resource exhaustion attacks.
Impact Assessment
Affected Systems: All Linux systems running kernel versions with the vulnerable DRM code, particularly those using:
- Modern AMD or Intel integrated graphics
- NVIDIA proprietary drivers with DRM support
- Display servers using property blobs (Wayland compositors, Xorg with modesetting driver)
Risk Level: Medium to High for multi-user systems and containers. Single-user desktop systems face lower risk but should still apply the fix.
Exploitability: The attack requires local access but no special privileges, making it relevant for shared hosting, container environments, and multi-user workstations.
Timeline and Resolution
The vulnerability was discovered through code audit rather than active exploitation. The fix is now in drm-misc-next and will be included in Linux kernel 6.20 or 7.0 (depending on final versioning). Distribution maintainers should backport this fix to stable kernels once it's accepted upstream.
System administrators can mitigate the issue temporarily by:
- Setting strict cgroup memory limits on user sessions
- Monitoring kernel log for OOM events
- Limiting access to DRM devices in containerized environments
This fix represents a small but crucial step in hardening the Linux graphics stack against resource exhaustion attacks, ensuring that modern GPU features don't compromise system stability and security boundaries.
Comments
Please log in or register to join the discussion