https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 01:36:58 +0000 https://vulnerability.circl.lu/vuln/cve-2026-31571 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/i915: Unlink NV12 planes earlier</p> <p>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.</p> <p>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.</p> <p>Rather than reverting to the old way of doing things, I think it&#39;s more clear if we unlink the NV12 planes before we even compute the new plane state.</p> <p>(cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc)</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/i915: Unlink NV12 planes earlier</p> <p>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.</p> <p>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.</p> <p>Rather than reverting to the old way of doing things, I think it&#39;s more clear if we unlink the NV12 planes before we even compute the new plane state.</p> <p>(cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc)</p> https://vulnerability.circl.lu/vuln/cve-2026-31571