Cloudanix VulnDB

CVE-2026-93183

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A startup error in the graphics driver for some older chips can crash the whole computer when certain debug settings are active.

Exploitation
Other
Attacker needs
None
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

lima_vm_create invokes drm_mm_init with va_start and va_end both zero before they are initialized, triggering DRM_MM_BUG_ON when DRM_DEBUG_MM is enabled and causing a kernel BUG / Oops crash.

Why it matters to the business

Boot-time kernel panic on affected ARM/Exynos devices when the kernel is compiled with DRM debug memory management, resulting in system unavailability until a fixed kernel is deployed.

How an attack unfolds

The flaw is triggered automatically during lima driver probe on vulnerable hardware with DRM_DEBUG_MM enabled; an attacker who can force a reboot or module load on such a system obtains a local denial of service via the resulting kernel BUG.

How to fix it

Rebuild or upgrade to a kernel containing the fix that moves the lima_vm_create call after va_start and va_end have been configured; disable DRM_DEBUG_MM in the interim if the driver must remain loaded.

How to confirm the fix worked

Confirm the lima driver source has lima_vm_create invoked after va range initialization; boot an affected device with DRM_DEBUG_MM enabled and verify absence of the drm_mm_init BUG in dmesg.

Typical attack path

  1. Boot or trigger deferred_probe_work_func on lima-equipped hardware
  2. lima_vm_create runs before va range setup
  3. drm_mm_init receives zero arguments and hits DRM_MM_BUG_ON
  4. Kernel BUG / Oops terminates the boot or crashes the system

How to detect it

Search kernel logs and dmesg for the strings 'drm_mm_init' together with 'lima_vm_create' and 'Internal error: Oops - BUG' on ARM systems.

What your security team should do

  • Prioritize kernel update on all systems using the lima DRM driver
  • Audit kernel configs for DRM_DEBUG_MM and disable where possible
  • Monitor boot logs on Exynos and similar ARM platforms for the described BUG pattern

The record

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.

Affected packages

Ecosystem Package Introduced Fixed