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

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

Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE
before enabling TRANS_DDI_FUNC_CTL.

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 TRANS_DDI_FUNC_CTL
as well. The DMC firmware also does the VRR restore in two stages:
- first stage seems to be unconditional and includes TRANS_VRR_CTL
and a few other VRR registers, among other things
- second stage is conditional on the DDI being enabled,
and includes TRANS_DDI_FUNC_CTL and TRANS_VRR_VMAX/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)
Published: 2026-05-13
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel DRM i915 driver contains a flaw where certain VRR registers are written before enabling the corresponding display function control. This incorrect order can trigger a Memory‑Corruption Event in the host’s System Management Controller and cause the entire kernel to hang. The issue manifests when a display link training fails and the device attempts to configure VRR parameters, leading to a full system stall.

Affected Systems

Any Linux kernel that includes the original i915 VRR implementation before the commit that reordered the register writes. The vulnerability is tied to the kernel itself and not to any particular Linux distribution or hardware other than the generic Linux platform.

Risk and Exploitability

The bug requires privileged kernel code and a specific display configuration that fails link training. An attacker with local access could potentially reproduce the hang by manipulating the HDMI/DP state or by connecting a monitor that causes link training to fail. No publicly known remote exploitation route exists, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. EPSS data is not available, and the CVSS score is not provided in the data set.

Generated by OpenCVE AI on May 13, 2026 at 17:37 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that reorders the VRR register writes (commit 93f3a267c3dd4d811b224bb9e179a10d81456a74) or update to a kernel version that contains the fix.
  • If updating the kernel immediately is not possible, disable VRR operation or avoid using external displays that may trigger link training failures.
  • Use reliable, high‑quality display cables and avoid known problematic docking configurations during the transition period.

Generated by OpenCVE AI on May 13, 2026 at 17:37 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 14 May 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-841
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

Wed, 13 May 2026 18:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-760

Wed, 13 May 2026 15:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE before enabling TRANS_DDI_FUNC_CTL. 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 TRANS_DDI_FUNC_CTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANS_VRR_CTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANS_DDI_FUNC_CTL and TRANS_VRR_VMAX/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)
Title drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-13T15:08:26.763Z

Reserved: 2026-05-01T14:12:56.011Z

Link: CVE-2026-43477

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-13T16:16:50.807

Modified: 2026-05-13T16:16:50.807

Link: CVE-2026-43477

cve-icon Redhat

Severity : Low

Publid Date: 2026-05-13T00:00:00Z

Links: CVE-2026-43477 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-13T18:30:46Z

Weaknesses