libdisplay-info CVE-2026-112271

The target software must link libdisplay-info version 0.4.0 or earlier and must parse an attacker-controlled EDID that contains a DisplayID v1 section in which a data block's declared length exceeds the remaining section bounds, driving is_all_zeroes to read past the heap buffer. Delivery requires local/physical means - a malicious monitor, KVM switch, video capture device, or a crafted EDID file fed to the parser - and passive user interaction such as connecting the device or opening the file (AV:L, UI:P). Limiting factors: no remote network vector, exploitation yields only a crash/denial of service (no code execution, no confidentiality or integrity impact per VC:N/VI:N), and it depends on the host application actually invoking the DisplayID v1 parser on untrusted EDID data.

This is a genuine but moderate-priority issue, not a top-tier emergency. The provided CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, VA:H with VC:N/VI:N) scores 6.8 (Medium) and is internally consistent with the description: the attack is local/physical in delivery (a malicious monitor, KVM, capture device, or EDID file), requires passive user interaction (connecting the device or loading the file), needs no privileges, and results only in an availability impact - a crash - with no confidentiality or integrity impact. No EPSS score, CISA KEV listing, or explicit POC flag was provided in the input, so there is no evidence of active or at-scale exploitation; a detailed third-party technical writeup (hackmd) and a VulnCheck advisory exist, which raise the practical likelihood of a working trigger EDID being reproduced, but that is distinct from confirmed exploitation. Note a signal conflict worth verifying: the input tag 'Information Disclosure' implies data leakage, yet the CVSS vector sets VC:N (no confidentiality impact) and the description states the result is 'a possible crash' - the realistic impact is denial of service, not disclosure. Because the attack vector is local and the outcome is a crash rather than code execution or data theft, real-world risk is low-to-moderate and concentrated in environments where untrusted displays/EDID data are parsed.

An attacker connects a malicious monitor, KVM, or HDMI/DisplayPort capture device (or convinces a user to load a crafted EDID file) to a system whose software links libdisplay-info ≤0.4.0. When the DisplayID v1 section is parsed, a data block whose declared length exceeds the section causes is_all_zeroes to read past the heap buffer, crashing the consuming application or compositor. No public exploit identified at time of analysis, though a detailed technical writeup of the flaw is referenced.