CVE-2026-80883 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X client is registered
The host1x_client_register() function is called just prior to register map initialization loop, making the device available to userspace. This may result in userspace attempting to submits a job before the register map is initialized. Address this by moving register initialization before host1x client registration.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified within the Linux kernel's DRM Tegra subsystem involves a critical race condition related to hardware resource initialization and device availability. Specifically, the issue arises in the gr2d and gr3d drivers which manage 2D and 3D graphics processing units on NVIDIA Tegra platforms. The core technical flaw lies in the sequence of operations during driver probe or initialization. Previously, the host1x_client_register function was invoked before the address register map for these hardware blocks was fully initialized. This registration step is significant because it exposes the device interface to userspace applications and higher-level graphics stacks, effectively marking the device as ready for use by external processes.
By registering the client with the HOST1X subsystem prior to completing the initialization of the internal register maps, a window of vulnerability is created where the operating system considers the hardware operational while its internal state remains undefined or incomplete. This timing discrepancy allows userspace applications to submit graphics jobs to the GPU before the necessary memory mappings and configuration registers are properly set up. When such premature job submissions occur, they interact with uninitialized or incorrectly mapped hardware resources, leading to unpredictable behavior. The consequences of this race condition can range from graphical corruption and rendering artifacts to system instability, including kernel panics or hangs, as the graphics processor attempts to execute commands against a misconfigured state.
From a security perspective, this flaw aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The lack of proper ordering in initialization routines allows an unprivileged userspace process to trigger undefined behavior within kernel-space drivers. Furthermore, this scenario can be mapped to the MITRE ATT&CK framework under techniques involving resource manipulation or exploitation of race conditions, although it is primarily a stability and reliability issue rather than a direct privilege escalation vector unless combined with other vulnerabilities. The impact extends beyond mere application crashes; in shared computing environments or systems relying on consistent graphical output for security monitoring interfaces, such instability can compromise the integrity of visual data presentation.
The resolution implemented by the Linux kernel maintainers addresses this flaw by reordering the initialization sequence within the driver code. The fix ensures that the address register map is fully initialized and mapped before calling host1x_client_register. This guarantees that when the device becomes available to userspace, all underlying hardware resources are in a known, stable state ready for command submission. This change eliminates the race window by enforcing strict dependency ordering between resource preparation and interface exposure.
To mitigate similar issues or verify this fix, system administrators should ensure their Linux kernels include patches from versions where this specific DRM Tegra initialization order was corrected. For developers working on embedded systems using NVIDIA Tegra chips, it is crucial to audit driver probe functions for proper sequencing of hardware registration versus resource mapping. Adhering to best practices in kernel development, such as ensuring all internal state is initialized before exposing interfaces via sysfs or character devices, prevents these types of race conditions. Regular updates to the graphics stack and kernel are recommended to maintain system stability and prevent potential denial-of-service scenarios arising from uninitialized hardware access.