Where
AND
-Infinity
0
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

drm/i915/vrr: Configure VRR timings after enabling TRANSDDIFUNCCTL

Apparently ICL may hang with an MCE if we write TRANSVRRVMAX/FLIPLINE before enabling TRANSDDIFUNCCTL.

Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the problem for whatever reason.

BSpec does tell us to configure VRR after enabling TRANSDDIFUNCCTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANSVRRCTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANSDDIFUNCCTL and TRANSVRRVMAX/VMIN/FLIPLINE, among other things

So let's reorder the steps to match to avoid the hang, and toss in an extra WARN to make sure we don't screw this up later.

BSpec: 22243 (cherry picked from commit 93f3a267c3dd4d811b224bb9e179a10d81456a74)

First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

drm/i915: Unlink NV12 planes earlier

unlinknv12plane() will clobber parts of the plane state potentially already set up by planeatomiccheck(), 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. planeatomiccheck() will first compute the proper plane state based on the userspace request, and unlinknv12plane() later clears some of the state.

This used to work on account of unlinknv12plane() 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 unlinknv12plane() 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)

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203