CVE-2026-90363: drm/msm: don't tear down KMS twice when KMS init fails
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: don't tear down KMS twice when KMS init fails
When priv->kmsinit() (mdp4kmsinit() / mdp5kmsinit()) fails partway through, both display drivers already tear their KMS state down via mdp4destroy() / mdp5kmsdestroy() before returning the error. The common error path in msmdrminit() then runs msmdrmuninit() -> msmdrmkmsuninit(), which tries to destroy the very same KMS a second time, which causes a use-after-free crash.
Bring MDP4/MDP5 in line with the DPU driver whose dpukmsinit() doesn't perform error cleanup on the failure. Let the common path own the cleanup, instead of freeing the KMS from their error paths.
The crash trace for the reference:
lockacquire from lockacquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863) lockacquire from touchwqlockdepmap (kernel/workqueue.c:4094 (discriminator 1)) touchwqlockdepmap from flushworkqueue (kernel/workqueue.c:4136) flushworkqueue from msmdrmkmsuninit (drivers/gpu/drm/msm/msmkms.c:243 (discriminator 33)) msmdrmkmsuninit from msmdrmuninit (drivers/gpu/drm/msm/msmdrv.c:93) msmdrmuninit from msmdrminit (drivers/gpu/drm/msm/msmdrv.c:184) msmdrminit from trytobringupaggregatedevice (drivers/base/component.c:249 drivers/base/component.c:227) trytobringupaggregatedevice from componentadd (drivers/base/component.c:269 drivers/base/component.c:748) componentadd from dsihostattach (drivers/gpu/drm/msm/dsi/dsihost.c:1739) dsihostattach from mipidsiattach (drivers/gpu/drm/drmmipidsi.c:383) mipidsiattach from sharpntpanelprobe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247)
Patchwork: https://patchwork.freedesktop.org/patch/742068/
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this failure mode?
Systems using the Linux kernel MSM DRM display drivers with MDP4 or MDP5 KMS initialization are affected when their KMS initialization fails partway through. The described issue does not identify DPU as affected.
What condition triggers the crash?
The trigger is a partial failure in priv->kms_init(), specifically mdp4_kms_init() or mdp5_kms_init(). Those paths free KMS state before returning an error, after which the common msm_drm_init() error path attempts to free the same state again.
How can I recognize that this issue has occurred?
The result is a use-after-free crash during KMS cleanup. The provided reference trace includes msm_drm_kms_uninit(), msm_drm_uninit(), and msm_drm_init(), with workqueue flushing and lock acquisition functions also present.
What is the remediation described by the fix?
MDP4 and MDP5 initialization failure paths must not tear down KMS state themselves. Cleanup should be left to the common error path, matching the DPU initialization behavior described in the fix.