CVE-2026-112007 in Schism Tracker
Summary
by MITRE • 10/18/2026
Schism Tracker through 20260524 contains a heap out-of-bounds write vulnerability in fmt_ult_load_song() in fmt/ult.c that fails to clamp the one-byte sample count to MAX_SAMPLES. Attackers can supply a crafted .ult module that overwrites the instruments pointer array, causing csf_destroy() to free attacker-chosen pointers and crash the application.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in Schism Tracker versions up through 20260524 represents a critical heap-based buffer overflow located within the fmt_ult_load_song function of the fmt/ult.c source file. This specific component is responsible for parsing and loading Ultimate Soundtracker module files, which are legacy audio formats still supported by many tracker applications due to their historical significance in music production. The core technical flaw stems from a failure to validate input data boundaries during the initialization phase of song loading. Specifically, when processing sample metadata embedded within the .ult file structure, the application fails to clamp or verify that the reported one-byte sample count does not exceed the predefined MAX_SAMPLES constant. This lack of bounds checking allows an attacker to craft a malicious module file containing an artificially inflated sample count value that surpasses the allocated memory limits for instrument pointers.
During execution, this unchecked integer value is used as an index or loop counter when populating the instruments pointer array in heap memory. Because the application does not enforce the maximum limit before writing data structures associated with each sample, it proceeds to write beyond the boundaries of the originally allocated buffer. This results in a heap out-of-bounds write condition where adjacent memory regions are overwritten. In this specific context, the overflow corrupts critical metadata or pointer arrays that manage instrument resources. The corruption is particularly dangerous because it directly affects the integrity of pointers stored within the application's internal data structures, setting up a subsequent exploitation vector during resource cleanup routines.
The operational impact of this vulnerability becomes most severe when the application attempts to unload or destroy the loaded song context via the csf_destroy function. This routine iterates through the instrument array and invokes deallocation functions on each pointer it encounters. Due to the prior heap corruption, these pointers no longer reference valid memory addresses allocated by the tracker but instead contain attacker-controlled values derived from the crafted .ult file. Consequently, when csf_destroy attempts to free these corrupted pointers, it triggers a crash or potentially allows for arbitrary code execution if the freed memory is later reallocated and used in a way that leverages the controlled pointer value. This scenario typically results in an immediate denial of service as the application terminates unexpectedly due to segmentation faults or heap corruption errors detected by modern operating system protections.
From a classification perspective, this vulnerability aligns with CWE-122 Heap-based Buffer Overflow, which describes writing data beyond the bounds of a buffer allocated on the heap. The exploitation technique relies on manipulating memory layout and pointer values, which corresponds to ATT&CK techniques related to Memory Corruption such as T1068 Exploitation for Privilege Escalation if local code execution is achieved, or more generally under Defense Evasion via process injection patterns if used in conjunction with other vectors. The primary risk vector involves the processing of untrusted media files, highlighting the importance of robust input validation in multimedia parsing libraries that are often exposed to user-supplied content.
Mitigation strategies for this vulnerability focus on enforcing strict bounds checking at the point of data ingestion. Developers must ensure that all numeric values extracted from external file formats, particularly those determining array sizes or loop iterations such as sample counts, are validated against their respective maximum limits before being used in memory allocation or indexing operations. Implementing defensive programming practices where MAX_SAMPLES is strictly enforced will prevent the out-of-bounds write condition. Additionally, employing static analysis tools and fuzz testing on module file parsers can help identify similar boundary violations across other supported formats. Users should update to patched versions of Schism Tracker that include these validation fixes and avoid opening .ult files from untrusted sources until remediation is applied.