CVE-2026-111153 in Game Music Emu
Summary
by MITRE • 10/15/2026
Game Music Emu (libgme) through 0.6.5 contains a global out-of-bounds read vulnerability in Classic_Emu::mute_voices_ that allows attackers to crash applications by supplying NSF files whose voice count exceeds the 16-entry voice-type table. Attackers can craft an NSF header with chip_flags 0x3F, opened through gme_open_data or gme_open_file, to read past the static array during loading and cause denial of service.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Game Music Emu (libgme) versions up to 0.6.5 represents a critical memory safety flaw located within the Classic_Emu::mute_voices_ function. This component is responsible for managing audio channels when processing NSF, or Nintendo Sound Format, files which are commonly used to emulate music from classic gaming systems such as the NES and Game Boy. The core technical defect arises from an insufficient validation of input data regarding voice counts before accessing a static array that defines up to sixteen distinct voice types. When an attacker supplies a maliciously crafted NSF file where the header indicates a number of voices exceeding this hardcoded limit, the application attempts to access memory locations beyond the bounds of the allocated array. This results in a global out-of-bounds read operation, allowing the program to retrieve uninitialized or irrelevant data from adjacent memory regions rather than failing gracefully with an error code.
From a technical perspective, this flaw is classified under CWE-125, which denotes Out-of-Bounds Read vulnerabilities. The exploitation mechanism relies on specific fields within the NSF file header, particularly the chip_flags field set to 0x3F and the voice count parameter. By invoking functions such as gme_open_data or gme_open_file with these crafted inputs, an attacker can trigger the erroneous memory access during the loading phase of the emulation process. The immediate operational impact is a denial of service condition, manifested as application crashes or segmentation faults. While out-of-bounds reads are sometimes associated with information disclosure if sensitive data resides in adjacent memory, in this specific context involving audio emulators and static arrays, the primary consequence observed is stability failure rather than direct credential theft or code execution. However, persistent exploitation could potentially lead to more severe outcomes depending on the surrounding memory layout and subsequent operations performed by the application after the read occurs.
This vulnerability aligns with ATT&CK technique T1496, Resource Hijacking, specifically in the context of denial-of-service attacks against software services that process untrusted media files. It also reflects common pitfalls described in CWE-20 regarding improper input validation where boundary checks are either missing or incorrectly implemented for array indices derived from external sources. The lack of rigorous bounds checking on user-supplied data before array indexing is a prevalent issue in legacy C and C++ codebases, particularly those dealing with binary file formats that may not have been designed with modern security assumptions in mind.
To mitigate this vulnerability, developers must implement strict input validation for all fields within the NSF header prior to processing or memory allocation. Specifically, the voice count value should be validated against the maximum supported limit of sixteen entries before any array access occurs. If the value exceeds this threshold, the application should reject the file and return an appropriate error code rather than attempting to process it. Additionally, employing static analysis tools that detect out-of-bounds accesses during development can help identify similar flaws in other parts of the codebase. For end-users, updating libgme to a patched version where these bounds checks have been enforced is essential to prevent exploitation. Security-conscious applications integrating this library should also consider implementing sandboxing or memory protection mechanisms such as Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) to limit the potential impact of any successful buffer over-reads, although mitigation at the source code level remains the most effective defense against CWE-125.