CVE-2026-98997 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: only accept doorbell BOs as queue doorbell
amdgpu_userq_get_doorbell_index() pins any BO passed as doorbell_handle into the doorbell domain. For a regular BO, TTM moves it with ttm_bo_move_null() and its contents are lost. Since an importer on the same device gets the exporter's GEM object, a client can do this to a buffer another client shared with it.
Reject BOs that were not created in the doorbell domain.
v2: drop the error message, use a local abo variable (Christian)
(cherry picked from commit f7497bbc19db4821c62b9d97b31c9086feb2d917)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the Linux kernel's AMDGPU driver, specifically within the user queue doorbell handling mechanism, represents a critical flaw in buffer object validation and memory management. The core issue resides in the amdgpu_userq_get_doorbell_index function, which is responsible for pinning buffer objects passed as doorbell handles into the dedicated doorbell domain of the GPU hardware. This operation assumes that any provided buffer object was originally created within the specific doorbell memory domain, ensuring its physical layout and accessibility are compatible with direct hardware access patterns required for signaling queue completion events. However, the implementation fails to verify this precondition before attempting to pin the buffer. When a regular buffer object, which resides in standard system or graphics memory domains rather than the specialized doorbell domain, is passed as a handle, the Translation Table Manager (TTM) subsystem attempts to move it using ttm_bo_move_null(). This operation effectively discards the original contents of the buffer because the driver does not properly map or preserve the data during this invalid transition.
This technical flaw creates a significant risk for local privilege escalation and denial of service attacks within multi-user environments where GPU resources are shared between different processes or clients. Since an importer on the same device can acquire a reference to an exporter's Graphics Execution Manager (GEM) object, a malicious client can exploit this lack of validation by passing a buffer handle that it does not own or that was created in an incompatible memory domain. By doing so, the attacker triggers the erroneous pinning and subsequent data loss operation on buffers belonging to other clients sharing the same GPU context. This results in the corruption or destruction of critical state information for legitimate applications, potentially causing crashes, undefined behavior, or the leakage of sensitive kernel memory if the corrupted buffer is later accessed by privileged code paths that expect valid data structures.
From a security architecture perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-119 Buffer Overflow within a non-boundary context, as it involves mishandling external inputs (buffer handles) without adequate domain verification. In the MITRE ATT&CK framework for enterprise environments, particularly regarding endpoint detection and response scenarios involving GPU acceleration, this behavior can be categorized under Tactic Execution with techniques related to resource hijacking or denial of service through kernel-level exploitation. The failure to enforce strict type checking on hardware-specific resources allows an unprivileged user to disrupt the stability of shared computing infrastructure, undermining the isolation guarantees expected in virtualized or containerized workloads that rely on GPU partitioning.
To mitigate this vulnerability, it is imperative to implement rigorous validation checks within the amdgpu_userq_get_doorbell_index function before any pinning operations are attempted. The driver must explicitly verify that the buffer object associated with the provided doorbell handle was created in the correct doorbell memory domain using appropriate GEM flags or internal metadata indicators. If a buffer does not meet this criterion, the operation should be rejected immediately with an error code such as -EINVAL, preventing any further interaction with the invalid resource. This fix ensures that only buffers specifically allocated for hardware signaling purposes are used for queue doorbells, thereby preserving data integrity and maintaining isolation between different clients sharing GPU resources. System administrators should ensure their kernels are updated to include this patch, which has been cherry-picked from upstream commit f7497bbc19db4821c62b9d97b31c9086feb2d917, to restore the intended security boundaries of the AMDGPU driver.