CVE-2026-80541 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate GEM_CREATE domain combinations
AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON().
Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl().
v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian)
(cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The Linux kernel's AMDGPU driver contains a validation flaw within the GEM_CREATE ioctl implementation that allows userspace to specify invalid memory domain combinations. The vulnerability stems from insufficient checks on the domain bits passed during buffer object creation. While the code previously verified that individual domain flags fell within the expected mask, it failed to enforce logical constraints regarding which domains could be combined in a single request. This oversight permits malicious or buggy applications to construct requests that mix incompatible memory types, such as combining CPU-accessible GTT and VRAM with specialized hardware-specific domains like DOORBELL, GDS, GWS, or OA.
This lack of validation leads directly to an out-of-bounds condition within the amdgpu_bo_placement_from_domain function. When invalid combinations are processed, the internal logic attempts to map these conflicting domains into a placement array that has a fixed maximum size defined by AMDGPU_BO_MAX_PLACEMENTS. Because the driver does not reject the illegal combination beforehand, it proceeds to populate this array beyond its allocated limits. This overflow triggers an immediate kernel panic via a BUG_ON assertion, resulting in a denial of service for the entire system or at least the GPU subsystem handling that context.
From a security perspective, this vulnerability is classified under CWE-20 as Improper Input Validation and aligns with ATT&CK technique T1499, Endpoint Denial of Service. The impact is significant because it allows an unprivileged userspace process to crash the kernel by exploiting a logic error in resource allocation validation. Such crashes can lead to system instability, data loss if unsaved work exists on affected devices, and potential disruption of critical services running on the host machine.
The resolution involves tightening the input validation logic within amdgpu_gem_create_ioctl. The fix introduces a helper function, renamed from amdgpu_gem_domain_valid to amdgpu_gem_are_domains_valid, which explicitly checks for prohibited combinations. It enforces that domain flags belonging to CPU, GTT, and VRAM categories may only be combined with each other under specific conditions, while specialized non-CPU/GTT/VRAM domains such as DOORBELL, GDS, GWS, or OA must be specified exclusively without mixing them with the general memory domains. Any request violating these rules now returns an EINVAL error code instead of proceeding to cause a kernel panic.
To mitigate this vulnerability in environments where patching may not be immediately feasible, administrators should restrict untrusted userspace access to GPU resources and ensure that applications interacting with the AMDGPU driver adhere strictly to documented API contracts. Regularly updating the Linux kernel and associated graphics drivers is essential to maintain system integrity against such logic-based denial of service attacks.