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

drm/i915: Unlink NV12 planes earlier

unlink_nv12_plane() will clobber parts of the plane state
potentially already set up by plane_atomic_check(), so we
must make sure not to call the two in the wrong order.
The problem happens when a plane previously selected as
a Y plane is now configured as a normal plane by user space.
plane_atomic_check() will first compute the proper plane
state based on the userspace request, and unlink_nv12_plane()
later clears some of the state.

This used to work on account of unlink_nv12_plane() skipping
the state clearing based on the plane visibility. But I removed
that check, thinking it was an impossible situation. Now when
that situation happens unlink_nv12_plane() will just WARN
and proceed to clobber the state.

Rather than reverting to the old way of doing things, I think
it's more clear if we unlink the NV12 planes before we even
compute the new plane state.

(cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc)

Project Subscriptions

Vendors Products
Linux Kernel Subscribe
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Sat, 25 Apr 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-366
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Fri, 24 Apr 2026 15:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: drm/i915: Unlink NV12 planes earlier unlink_nv12_plane() will clobber parts of the plane state potentially already set up by plane_atomic_check(), so we must make sure not to call the two in the wrong order. The problem happens when a plane previously selected as a Y plane is now configured as a normal plane by user space. plane_atomic_check() will first compute the proper plane state based on the userspace request, and unlink_nv12_plane() later clears some of the state. This used to work on account of unlink_nv12_plane() skipping the state clearing based on the plane visibility. But I removed that check, thinking it was an impossible situation. Now when that situation happens unlink_nv12_plane() will just WARN and proceed to clobber the state. Rather than reverting to the old way of doing things, I think it's more clear if we unlink the NV12 planes before we even compute the new plane state. (cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc)
Title drm/i915: Unlink NV12 planes earlier
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-04-24T14:35:50.094Z

Reserved: 2026-03-09T15:48:24.117Z

Link: CVE-2026-31571

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-04-24T15:16:31.653

Modified: 2026-04-24T17:51:40.810

Link: CVE-2026-31571

cve-icon Redhat

Severity : Low

Publid Date: 2026-04-24T00:00:00Z

Links: CVE-2026-31571 - Bugzilla

cve-icon OpenCVE Enrichment

No data.

Weaknesses