CVE-2026-111152 in Game Music Emu
Summary
by MITRE • 10/15/2026
Game Music Emu (libgme) through 0.6.5 contains a heap out-of-bounds read vulnerability in the AY loader get_data function caused by an integer underflow in the track-table bounds check. Attackers can supply a crafted ZXAYEMUL file with an oversized track table to read past the file buffer via gme_track_info or gme_start_track, crashing libgme consumers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within Game Music Emu, specifically in versions through 0.6.5, represents a critical memory safety issue located within the AY loader component of the library known as libgme. This flaw manifests as a heap out-of-bounds read, which is triggered by an integer underflow during the validation logic for track-table bounds checks. The core technical failure lies in how the software calculates and verifies array indices when processing metadata associated with ZX Spectrum AY emulator files. When the application parses these specific audio formats, it relies on numerical values embedded within the file structure to determine the size of internal data structures. Due to insufficient type checking or improper handling of signed versus unsigned integer arithmetic during this validation phase, an attacker can manipulate input parameters such that a subtraction operation results in a negative value that wraps around to a large positive number when interpreted as an unsigned integer. This underflow causes the bounds check to pass erroneously, allowing subsequent memory access operations to proceed without proper boundary verification.
The operational impact of this vulnerability is significant for any application or service that utilizes libgme to parse and render game music files. By supplying a specially crafted ZXAYEMUL file containing an oversized track table relative to the allocated buffer size, an attacker can force the library to read memory locations beyond the intended heap allocation boundaries. This out-of-bounds access is typically executed when functions such as gme_track_info or gme_start_track are invoked on the malicious input. The immediate consequence of this unauthorized memory read is often a segmentation fault or application crash, leading to a denial of service for legitimate users relying on the software. However, beyond simple instability, out-of-bounds reads can potentially leak sensitive information from adjacent heap regions if the attacker carefully crafts the payload to align with specific data structures containing confidential values. While exploitation for arbitrary code execution is less common with read-only vulnerabilities compared to write variants, the ability to probe memory contents poses a serious risk in contexts where libgme processes untrusted audio assets provided by external sources or users.
From a classification perspective, this vulnerability aligns closely with CWE-190, which describes integer overflow or wraparound errors that lead to subsequent security weaknesses such as buffer overflows or out-of-bounds accesses. The specific mechanism of reading memory outside allocated bounds corresponds directly to CWE-125, an out-of-bounds read condition. In the context of offensive cybersecurity frameworks like MITRE ATT&CK, this behavior facilitates reconnaissance activities where an adversary might attempt to gather information about the target system's memory layout or extract sensitive data through side-channel effects resulting from the unauthorized reads. The vulnerability highlights a common pitfall in C and C++ programming where developers fail to account for arithmetic underflows when performing boundary checks on array indices derived from untrusted input, particularly when mixing signed and unsigned types without explicit casting or validation.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is the deployment of updated versions of libgme that have addressed this integer underflow issue by implementing robust type checking and ensuring that all arithmetic operations related to buffer sizes are performed using unsigned types with explicit overflow checks before allocation or access occurs. Developers integrating libgme into their applications should ensure they are linking against patched libraries and consider implementing input validation layers at the application level to sanitize file headers before passing them to the library. Furthermore, adopting static analysis tools that detect integer underflow patterns during development can prevent similar defects in future code revisions. Runtime protections such as Address Sanitizer (ASan) or Heap Buffer Overflow detection mechanisms should be enabled during testing phases to identify and isolate these memory safety violations early in the software lifecycle.