CVE-2026-89599: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display
In the Linux kernel, the following vulnerability has been resolved:
fbdev: omapfb: panel-dsi-cm: initialize lock before registering display
dsicmprobe() registers the display before initializing ddata->lock. Once omapdssregisterdisplay() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized.
Initialize the mutex before registering the display so the published callbacks always see a valid lock.
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux kernel's fbdev omapfb panel-dsi-cm driver are relevant. The issue occurs during dsicm_probe() when the display is published before its mutex has been initialized.
What must happen for the issue to be triggered?
After omapdss_register_display() publishes the display, another consumer must invoke a dsicm callback that takes ddata->lock before dsicm_probe() initializes that mutex.
What is the available remediation?
Apply a kernel update containing the fix that initializes ddata->lock before registering the display. The provided stable kernel references identify commits containing the correction.