Description
In the Linux kernel, the following vulnerability has been resolved:

drm/msm: don't tear down KMS twice when KMS init fails

When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway
through, both display drivers already tear their KMS state down via
mdp4_destroy() / mdp5_kms_destroy() before returning the error. The
common error path in msm_drm_init() then runs msm_drm_uninit() ->
msm_drm_kms_uninit(), 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 dpu_kms_init() 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:

__lock_acquire from lock_acquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863)
lock_acquire from touch_wq_lockdep_map (kernel/workqueue.c:4094 (discriminator 1))
touch_wq_lockdep_map from __flush_workqueue (kernel/workqueue.c:4136)
__flush_workqueue from msm_drm_kms_uninit (drivers/gpu/drm/msm/msm_kms.c:243 (discriminator 33))
msm_drm_kms_uninit from msm_drm_uninit (drivers/gpu/drm/msm/msm_drv.c:93)
msm_drm_uninit from msm_drm_init (drivers/gpu/drm/msm/msm_drv.c:184)
msm_drm_init from try_to_bring_up_aggregate_device (drivers/base/component.c:249 drivers/base/component.c:227)
try_to_bring_up_aggregate_device from __component_add (drivers/base/component.c:269 drivers/base/component.c:748)
__component_add from dsi_host_attach (drivers/gpu/drm/msm/dsi/dsi_host.c:1739)
dsi_host_attach from mipi_dsi_attach (drivers/gpu/drm/drm_mipi_dsi.c:383)
mipi_dsi_attach from sharp_nt_panel_probe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247)

Patchwork: https://patchwork.freedesktop.org/patch/742068/
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Kernel Crash (Denial of Service)
Action: Immediate Patch
AI Analysis

Impact

This vulnerability arises when the msm DRM driver’s initialization fails; the driver tears down its kernel mode setting (KMS) state twice, producing a use‑after‑free that triggers a kernel panic. It results in a denial of service at the kernel level.

Affected Systems

The defect is confined to Linux kernel’s msm DRM driver, specifically the MDP4 and MDP5 subsystems. No specific kernel version range is supplied, so any kernel that includes the unpatched path is vulnerable.

Risk and Exploitability

The EPSS score is below 1 %. The vulnerability is not listed in KEV. The description does not provide explicit details on the conditions an attacker would need to trigger the double teardown. The crash occurs during driver initialization and brings the system down to a kernel panic.

Generated by OpenCVE AI on September 19, 2026 at 14:56 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that contains the fix for the double teardown in the msm DRM driver.
  • If a kernel update is not immediately possible, unload or blacklist the msm, mdp4, and mdp5 kernel modules until the patch is applied to prevent the crash from occurring.
  • Continuously monitor kernel logs (e.g., dmesg, /var/log/kern.log) for drm/msm‑related panic messages and investigate any unexpected init failures to confirm whether the vulnerability has been triggered.

Generated by OpenCVE AI on September 19, 2026 at 14:56 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 15:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: drm/msm: don't tear down KMS twice when KMS init fails When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway through, both display drivers already tear their KMS state down via mdp4_destroy() / mdp5_kms_destroy() before returning the error. The common error path in msm_drm_init() then runs msm_drm_uninit() -> msm_drm_kms_uninit(), 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 dpu_kms_init() 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: __lock_acquire from lock_acquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863) lock_acquire from touch_wq_lockdep_map (kernel/workqueue.c:4094 (discriminator 1)) touch_wq_lockdep_map from __flush_workqueue (kernel/workqueue.c:4136) __flush_workqueue from msm_drm_kms_uninit (drivers/gpu/drm/msm/msm_kms.c:243 (discriminator 33)) msm_drm_kms_uninit from msm_drm_uninit (drivers/gpu/drm/msm/msm_drv.c:93) msm_drm_uninit from msm_drm_init (drivers/gpu/drm/msm/msm_drv.c:184) msm_drm_init from try_to_bring_up_aggregate_device (drivers/base/component.c:249 drivers/base/component.c:227) try_to_bring_up_aggregate_device from __component_add (drivers/base/component.c:269 drivers/base/component.c:748) __component_add from dsi_host_attach (drivers/gpu/drm/msm/dsi/dsi_host.c:1739) dsi_host_attach from mipi_dsi_attach (drivers/gpu/drm/drm_mipi_dsi.c:383) mipi_dsi_attach from sharp_nt_panel_probe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247) Patchwork: https://patchwork.freedesktop.org/patch/742068/
Title drm/msm: don't tear down KMS twice when KMS init fails
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:09:06.817Z

Reserved: 2026-09-11T19:38:34.807Z

Link: CVE-2026-90363

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:35.353

Modified: 2026-09-17T17:17:35.353

Link: CVE-2026-90363

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T15:00:12Z

Weaknesses