CVE-2026-64050: drm/msm/dpu: don't mix devm and drmm functions

Q: Who is exposed to this issue?

Systems using the Linux kernel msm DPU driver with the writeback (WB) connector are exposed when the DRM device is torn down while userspace still holds a reference to that device.

Q: What does an attacker or local user need to trigger the flaw?

A local user needs to retain a userspace reference to the DRM device and interact with the WB connector during or after msm driver teardown. The provided vector indicates local access, low attack complexity, low privileges, and no user interaction are required.

Q: Is there a mitigation if the fix cannot be applied immediately?

The available information identifies the triggering condition as userspace retaining DRM-device references across msm driver teardown. Limiting access to the affected DRM device and avoiding teardown while such references remain may reduce exposure, but no supported workaround is provided.

Q: How can I determine whether a system needs the fix?

Check whether the kernel uses the msm DPU driver and its writeback connector. The remediation changes dpu_writeback_init() to use drmm-managed allocation rather than mixing devm and drmm allocation lifetimes.

Published Jul 19, 2026

Updated

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

drm/msm/dpu: don't mix devm and drmm functions

Mixing devm and drmm functions will result in a use-after-free on msm driver teardown if userspace keeps a reference on the drm device: The WB connector data will be destroyed because of the use of devmkzalloc()), while the usersoace still can try interacting with the WB connector (which uses drmm functions).

Change dpuwritebackinit() to use drmm.

Patchwork: https://patchwork.freedesktop.org/patch/722656/

Affected Software

7 affected components

Linux Linux kernel

Linux Linux kernel>=6.18<6.18.34

Linux Linux kernel>=6.19<7.0.11

Linux Linux kernel=7.1-rc1

Linux Linux kernel=7.1-rc2

Linux Linux kernel=7.1-rc3

Linux Linux kernel=7.1-rc4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Configuration
Change dpu_writeback_init() to use drmm_ functions instead of devm_ functions, avoiding mixing devm and drmm resource management for the writeback connector.
Linux kernel drm/msm/dpu dpu_writeback_init() memory allocation = drmm_

Event History

Jul 19, 2026

CVE Published

via MITRE·03:39 PM

Data Sourced

via MITRE·03:39 PM

DescriptionSeverity

Data Sourced

via NVD·04:17 PM

RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

Who is exposed to this issue?

Systems using the Linux kernel msm DPU driver with the writeback (WB) connector are exposed when the DRM device is torn down while userspace still holds a reference to that device.

What does an attacker or local user need to trigger the flaw?

A local user needs to retain a userspace reference to the DRM device and interact with the WB connector during or after msm driver teardown. The provided vector indicates local access, low attack complexity, low privileges, and no user interaction are required.

Is there a mitigation if the fix cannot be applied immediately?

The available information identifies the triggering condition as userspace retaining DRM-device references across msm driver teardown. Limiting access to the affected DRM device and avoiding teardown while such references remain may reduce exposure, but no supported workaround is provided.

How can I determine whether a system needs the fix?

Check whether the kernel uses the msm DPU driver and its writeback connector. The remediation changes dpu_writeback_init() to use drmm-managed allocation rather than mixing devm and drmm allocation lifetimes.

CVE-2026-64050: drm/msm/dpu: don't mix devm and drmm functions

Affected Software

Remediation

Event History

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker or local user need to trigger the flaw?

Is there a mitigation if the fix cannot be applied immediately?

How can I determine whether a system needs the fix?

Company

Resources

Contact

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker or local user need to trigger the flaw?

Is there a mitigation if the fix cannot be applied immediately?

How can I determine whether a system needs the fix?