LiveActive security incident?Get immediate response
CVE Record

CVE-2021-47444: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read

In the Linux kernel, the following vulnerability has been resolved: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") the function connector_bad_edid() started assuming that the memory for the EDID passed to it was big enough to hold `edid[0x7e] + 1` blocks of data (1 extra for the base block). It completely ignored the fact that the function was passed `num_blocks` which indicated how much memory had been allocated for the EDID. Let's fix this by adding a bounds check. This is important for handling the case where there's an error in the first block of the EDID. In that case we will call connector_bad_edid() without having re-allocated memory based on `edid[0x7e]`.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

A Linux kernel display-handling bug could make the kernel trust an EDID extension count that exceeds the memory actually read from a monitor. This is primarily relevant to systems processing display data from attached hardware. The public record does not provide CVSS, confirmed impact, or active exploitation evidence.

Executive priority

Treat as a targeted kernel maintenance issue until more impact data exists. Patch through normal kernel update processes, with higher priority for systems exposed to untrusted display peripherals or physical-access scenarios.

Technical view

The DRM EDID path in connector_bad_edid() assumed edid[0x7e] + 1 blocks were available and ignored the num_blocks allocation boundary. The fix caps the extension count by the number of blocks actually read, preventing out-of-bounds EDID access when the first block has errors.

Likely exposure

Linux systems running affected kernel versions or downstream kernels containing the vulnerable DRM EDID code. Exposure is most plausible on endpoints, kiosks, appliances, or servers that parse EDID from monitors, adapters, docks, or KVMs.

Exploitation context

The provided sources do not show active exploitation, and CISA KEV status is false. Practical exploitation would likely require malformed or faulty EDID data reaching the kernel display stack, but the public bundle does not document exploitability or impact.

Researcher notes

The source bundle identifies a bounds-check fix but lacks CVSS, CWE, crash details, data disclosure claims, or privilege-impact analysis. Avoid overstating severity; focus validation on vulnerable commit lineage and whether downstream kernels include the fix.

Mitigation direction

  • Update to a vendor-supported kernel containing the referenced stable fixes.
  • Check distribution advisories for backported fixes before relying on version numbers alone.
  • Limit use of untrusted displays, adapters, docks, or KVMs on unpatched systems.
  • Prioritize remediation for exposed kiosks, workstations, and hardware test environments.

Validation and detection

  • Inventory Linux kernel versions and downstream distro patch levels.
  • Confirm whether the stable DRM EDID commits are present in deployed kernels.
  • Identify systems that regularly connect to untrusted display hardware.
  • Review vendor advisories for any additional operational mitigations or impact notes.
Prepared
Confidence
medium
Sources
5

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2021-47444 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
2ADP providers
4Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
CVECVE Program Container
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxe11f5bd8228fc3760c221f940b9f6365dbf3e7ed, e11f5bd8228fc3760c221f940b9f6365dbf3e7ed, e11f5bd8228fc3760c221f940b9f6365dbf3e7edunaffected
LinuxLinux5.7, 0, 5.10.75, 5.14.14, 5.15affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.