CVE-2026-89599

What it actually does

A local race in the Linux kernel OMAP framebuffer DSI command-mode panel driver (fbdev/omapfb/panel-dsi-cm) publishes the display via omapdss_register_display() before ddata->lock is initialized. After registration, another consumer can invoke a dsicm callback that takes that mutex while it is still uninitialized, producing undefined kernel lock state, memory corruption, oops/panic, or potentially arbitrary kernel read/write.

Why it matters to the business

Devices that actually ship this OMAP display driver—typically embedded, industrial, automotive, or IoT Linux systems rather than general-purpose servers—can suffer sudden kernel crashes (availability loss) or, in a worst case, local takeover of the OS. The issue needs local access, has no public exploit, is not in CISA KEV, and EPSS remains very low and flat (~0.14% over 30 days). Urgency is highest for fleets that load omapfb/panel-dsi-cm and lower everywhere else.

How an attack unfolds

An attacker who already has local code execution on a system whose kernel includes the panel-dsi-cm driver waits for or forces dsicm_probe(). Because the display is registered before the driver mutex is initialized, they race a concurrent consumer (another thread, process, or display stack callback) so that a dsicm callback acquires ddata->lock while it is still uninitialized. Kernel use of an uninitialized mutex can corrupt lock metadata or adjacent memory; depending on timing, lock debugging, and kernel config this usually panics the box but can theoretically be steered toward privilege escalation. No named threat actors, ransomware campaigns, or public exploit code are associated with this CVE.

How to fix it

Apply the upstream Linux kernel fix that calls mutex_init on ddata->lock before omapdss_register_display() in dsicm_probe(), then reboot onto the patched kernel. Consume the patched kernel from your distro, SoC vendor, or device OEM as soon as it is available; no per-package version list was published with this record, so confirm the changelog contains the panel-dsi-cm lock-ordering fix. If the display panel is unused, blacklist or do not build/load panel-dsi-cm/omapfb as a compensating control until the patched kernel is deployed.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes fbdev omapfb panel-dsi-cm (module or built-in) and whether dsicm_probe() still registers the display before initializing ddata->lock. After patching, verify the installed kernel changelog or source shows mutex initialization before omapdss_register_display(), that the module loads without oops, and that display bring-up no longer races. Systems without OMAP DSS/omapfb can be treated as not affected.

Typical attack path

1. Gain local access to a Linux system using an OMAP SoC (or a kernel build) that includes the panel-dsi-cm driver
2. Cause or wait for dsicm_probe() so omapdss_register_display() publishes the display before ddata->lock is initialized
3. Concurrently open or operate on the newly registered display so a dsicm callback takes the still-uninitialized mutex
4. Trigger undefined kernel lock/memory behavior (typically oops/panic; theoretically memory corruption usable for local privilege escalation)
5. If corruption is controllable, elevate from an unprivileged local context to kernel/root; otherwise deny service by crashing the host

How to detect it

Successful silent exploitation of this race is unlikely to leave unique network or file IOCs. Hunt host kernel logs (dmesg, journalctl -k, pstore/ ramoops, vmcore/crash dumps) around driver probe and display registration for mutex/lock debugging warnings, oops/BUG traces involving dsicm_* or panel-dsi-cm, and panics shortly after omapdss display registration. Correlate with local process activity that opened framebuffer/DSS devices at the same time. Absence of these crashes does not prove the race was not hit on kernels without lock debugging.

• panel-dsi-cm
• dsicm_probe
• omapdss_register_display
• Call Trace:.*dsicm_
• BUG:.*mutex
• DEBUG_LOCKS_WARN_ON
• lock->magic
• omapfb

What your security team should do

• Inventory Linux embedded/OMAP images for panel-dsi-cm or omapfb and prioritize those hosts for kernel updates
• Deploy vendor/distro kernels that initialize the dsicm mutex before display registration and reboot
• If the driver is not required, blacklist it until the patched kernel is in production
• Treat as a local kernel-memory-safety issue: enforce unprivileged local-access controls and restrict who can load modules or exercise the display stack
• Track distro/OEM advisories; there is no KEV deadline and EPSS is stable and low, so do not preempt higher-urgency remote KEVs unless you run this driver at scale