CVE-2026-116725 in gbsplay
Summary
by MITRE • 10/27/2026
gbsplay through 0.0.103 contains an out-of-bounds read vulnerability in mapper_map() in mapper.c that fails to reject ROM bank indexes beyond the ROM size, causing an underflowed bank length. Attackers can supply crafted .gbr, .gbs or .gb files with malicious bank indexes to make bank_get() read far past the heap ROM buffer and crash the player.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in gbsplay version 0.0.103 represents a critical memory safety flaw located within the mapper_map function of the source file mapper.c. This component is responsible for handling bank switching logic, which is essential for accessing data and code segments that exceed the initial addressable space of Game Boy ROM files. The core technical defect lies in the failure to validate input parameters against the total size of the loaded ROM image before performing arithmetic operations on bank indexes. Specifically, when a maliciously crafted .gbr, .gbs, or .gb file is processed, it can supply a bank index that exceeds the actual number of banks available in the ROM header. Instead of rejecting this invalid input with an appropriate error code, the application proceeds to calculate the length and offset for the requested bank using underflowed values due to integer arithmetic issues or lack of boundary checks.
This logical flaw directly leads to an out-of-bounds read condition where the program attempts to access memory locations far beyond the allocated heap buffer containing the ROM data. In C-based applications, such as gbsplay which is typically written in this language, accessing memory outside the bounds of a declared array or buffer results in undefined behavior. The immediate operational impact observed during exploitation is a segmentation fault causing the player application to crash abruptly. While the primary manifestation described is a denial-of-service through application termination, out-of-bounds reads can potentially lead to more severe consequences depending on the surrounding memory layout and compiler optimizations. An attacker could theoretically leverage this vulnerability to leak sensitive information from adjacent heap structures or stack frames if specific conditions are met, although the current description emphasizes the crash scenario as the primary risk vector for end-users interacting with untrusted game files.
From a classification perspective, this issue aligns closely with CWE-125, which defines out-of-bounds read vulnerabilities where software reads data past the end or before the beginning of the intended buffer. The root cause is categorized under CWE-20, improper input validation, as the application fails to sanitize and verify that the bank index provided by the ROM file falls within the valid range determined by the ROM size. In terms of attack vectors, this vulnerability facilitates local exploitation through maliciously crafted media files, which corresponds to ATT&CK technique T1566.002, specifically Phishing: Spearphishing Attachment if delivered via email or general social engineering tactics involving game distribution platforms. The lack of bounds checking allows an adversary to trigger the flaw simply by convincing a user to open a specially constructed file within the supported formats.
Mitigation strategies must focus on rigorous input validation and defensive programming practices within the mapper module. Developers should implement explicit checks that compare the requested bank index against the maximum valid bank count derived from the ROM header before any arithmetic operations are performed on offsets or lengths. If an invalid bank index is detected, the application should immediately halt processing of that file and return a clear error message to the user rather than proceeding with memory access operations. Additionally, employing static analysis tools configured to detect buffer overflows and out-of-bounds accesses during the development phase can help identify similar logical errors in other parts of the codebase. Updating gbsplay to patched versions where these boundary checks are enforced is essential for maintaining system integrity and preventing unauthorized crashes or potential information disclosure through crafted game files.