CVE-2026-112271 in libdisplay-info
Summary
by MITRE • 10/19/2026
libdisplay-info through 0.4.0 contains a heap out-of-bounds read vulnerability in the DisplayID v1 section parser in displayid.c that occurs when a data block's declared length exceeds the section. Attackers can supply a crafted EDID from a malicious monitor, KVM, capture device, or EDID file to make is_all_zeroes read past the buffer, causing a possible crash.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in libdisplay-info versions through 0.4.0 represents a critical heap-based out-of-bounds read flaw located within the DisplayID version one section parser implementation found in displayid.c. This specific weakness arises from an insufficient boundary check when parsing data blocks that are part of the Extended Display Identification Data structure. The core technical failure occurs when a malicious actor supplies a crafted EDID payload where the declared length field for a specific data block exceeds the actual size of the containing section or buffer allocated by the library. Instead of validating that the sum of offsets and lengths remains within the bounds of the available memory, the parser proceeds to read from an invalid memory location. This logic error allows the application function is_all_zeroes to access memory addresses beyond the intended heap allocation, leading to a potential denial of service condition manifested as a crash or segmentation fault when the out-of-bounds data cannot be accessed due to operating system memory protection mechanisms.
From a threat actor perspective, this vulnerability can be exploited by connecting a malicious peripheral device such as an unauthorized monitor, a rogue KVM switch, or a hardware capture device that injects malformed EDID packets during the initialization handshake with the host system. Alternatively, attackers could distribute crafted EDID files through social engineering vectors to trick users into loading them via applications that utilize libdisplay-info for display configuration analysis. The operational impact of this flaw is primarily centered on availability, as successful exploitation results in application instability or termination. While heap out-of-bounds reads are sometimes associated with information disclosure if the accessed memory contains sensitive data, in this specific context involving simple zero-checking logic and typical EDID parsing workflows, the most immediate and likely consequence is a crash rather than arbitrary code execution or significant data leakage. However, depending on the surrounding application architecture and heap layout, such memory corruption could theoretically be chained with other vulnerabilities to achieve more severe outcomes like remote code execution.
This vulnerability aligns closely with Common Weakness Enumeration identifier CWE-125, which describes out-of-bounds read errors where software reads past the end of a buffer or array. It also relates to CWE-20 regarding improper input validation, as the parser fails to correctly validate that declared block lengths are consistent with the actual section size before proceeding with memory access operations. In terms of offensive security frameworks, this exploitation vector corresponds to MITRE ATT&CK technique T1563, specifically Remote Service Session Hijacking or injection via peripheral devices, where an attacker leverages physical or network-accessible hardware interfaces to inject malicious data structures into the target system's display subsystem. The attack path typically involves intercepting or spoofing Display Data Channel communications to deliver the malformed EDID payload during the initial connection phase of a monitor or capture device.
Mitigation strategies for this vulnerability require immediate updates to libdisplay-info version 0.4.1 or later, where the parsing logic has been corrected to enforce strict bounds checking on all data block lengths relative to their parent sections. For organizations unable to patch immediately, defensive measures should include implementing network segmentation to restrict access to display management services from untrusted networks and deploying input validation filters at the application layer that reject EDID structures with inconsistent length fields before they reach the vulnerable parser function. Additionally, enabling heap protection mechanisms such as Address Sanitizer in development environments or using runtime memory safety tools can help detect similar issues during testing phases. Security teams should also audit any custom applications relying on libdisplay-info to ensure they are not passing untrusted EDID data from external sources without rigorous validation and sanitization procedures.