CVE-2026-93183 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: call drm_mm_init() with a valid allocation range
lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2:
[ 1.736297] ------------[ cut here ]------------
[ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931!
[ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 1.750697] Modules linked in:
[ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT
[ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree)
[ 1.769446] Workqueue: events_unbound deferred_probe_work_func
[ 1.775261] PC is at drm_mm_init+0x9c/0xa4
[ 1.779339] LR is at lima_vm_create+0x144/0x17c
[ ... ]
Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel driver for the Lima GPU, a Mali-4xx series implementation used in various ARM-based SoCs such as those from Samsung Exynos, contained a critical initialization sequence error within its virtual memory management subsystem. The vulnerability manifests during the early stages of device probe when the graphics processing unit is being initialized by the operating system. Specifically, the function lima_vm_create was invoked before the virtual address range boundaries were properly established via va_start and va_end calls. This sequencing flaw resulted in these boundary variables remaining at their default zero values, which are then passed directly to drm_mm_init as parameters defining the valid allocation range for memory management structures.
From a technical perspective, this constitutes an improper initialization of resource allocation ranges, leading to invalid state assumptions within the DRM memory manager subsystem. The drm_mm_init function includes strict validation checks designed to ensure that the provided start and end addresses form a coherent and non-degenerate address space. When zero values are supplied for both parameters, the internal BUG_ON macro triggers immediately because it detects an illegal or empty allocation range. This results in a kernel panic on systems where DRM_DEBUG_MM debugging is enabled, effectively causing a denial of service condition during boot or device initialization phases. The crash occurs within the core memory management code path, specifically at drm_mm_init, as evidenced by stack traces showing execution flow from lima_vm_create into the faulty validation logic.
The operational impact of this vulnerability is primarily localized to system stability and availability rather than security exploitation in the traditional sense. Since the flaw triggers a kernel BUG_ON, it causes an immediate halt or reboot of the affected device during startup if debug logging for memory management is active. While most production kernels may have such debugging flags disabled by default, preventing the crash from occurring routinely, the presence of this code path represents a latent defect that could be triggered under specific configuration scenarios or through automated testing frameworks that enable detailed kernel diagnostics. Furthermore, it indicates poor architectural design in the driver initialization sequence where dependencies between setup functions were not properly ordered, potentially leading to undefined behavior even if the BUG_ON check is bypassed by disabling debug flags.
In terms of industry standard classifications, this issue aligns with CWE-665 improper initialization and CWE-823 use of outdated or incorrect resource management practices. The error reflects a failure in ensuring that prerequisites for a function are met before execution, which can be mapped to ATT&CK technique T1499 endpoint denial of service if the vulnerability is leveraged to crash systems during deployment or maintenance windows where verbose logging might be enabled by administrators. Although not directly exploitable for privilege escalation due to its nature as an initialization error rather than a memory corruption flaw allowing arbitrary code execution, it highlights critical weaknesses in driver robustness and defensive programming practices within kernel subsystems handling hardware resources.
Mitigation strategies involve applying the upstream patch that reorders the function calls so that lima_vm_create is executed only after va_start and va_end have been correctly initialized with valid address ranges. System administrators should ensure their kernels are updated to include this fix, particularly for devices based on Exynos 4412 or similar platforms utilizing the Lima driver. Additionally, developers reviewing GPU drivers should enforce strict initialization ordering constraints in code reviews to prevent similar sequencing errors where dependent components rely on variables that have not yet been populated with valid data. Regular static analysis and runtime validation checks can help identify such logical flaws before they reach production environments.