CVE-2026-111131 in libxmp
Summary
by MITRE • 10/15/2026
libxmp through 4.7.4 contains an off-by-one stack out-of-bounds read vulnerability in the prowizard P61A depacker depack_p61a() in src/loaders/prowizard/p61a.c. Attackers can supply a crafted headerless P61A module with 31 samples and a 0xffe0 back-reference size word to leak stack memory into sample metadata or disrupt loading.
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 libxmp versions through 4.7.4 represents a critical security flaw within the prowizard P61A depacker, specifically located in the depack_p61a function found in src/loaders/prowizard/p61a.c. This component is responsible for decompressing and processing module files formatted according to the P61A specification, which was historically used by certain tracker software on older computing platforms. The core of the issue lies in an off-by-one error during the handling of back-reference sizes within compressed data streams. When the depacker processes a crafted input file that lacks a standard header but contains exactly thirty-one samples and specifies a back-reference size word with the value 0xffe0, it triggers an out-of-bounds read operation on the stack memory space allocated for local variables and function context. This specific condition allows the application to access one byte beyond the intended buffer boundary, leading to unintended data exposure or control flow disruption depending on how the leaked information is subsequently utilized by the loading routine.
From a technical perspective, this vulnerability falls under the category of CWE-125, which denotes Out-of-bounds Read. The root cause stems from insufficient bounds checking during the decompression algorithm's execution loop. In many legacy module formats, back-references are used to efficiently encode repeated data patterns by pointing to previous bytes in the stream rather than storing them explicitly. When the depacker encounters a large back-reference size such as 0xffe0, it attempts to copy that amount of data from a source pointer relative to the current position. Due to an off-by-one miscalculation in the loop termination condition or index arithmetic, the read operation extends one byte past the allocated stack buffer. This behavior is particularly dangerous because stack memory often contains sensitive information such as return addresses, local variable values, and potentially cryptographic keys if they are stored locally during processing. The absence of a header in the crafted module further complicates validation efforts, as standard sanity checks that might normally reject malformed files based on structural inconsistencies may be bypassed or rendered ineffective by the specific layout of this attack vector.
The operational impact of exploiting this vulnerability is twofold: information disclosure and potential denial of service. By leaking stack memory into sample metadata structures, an attacker can extract sensitive data from the process address space. This could include partial contents of other variables, pointers to heap allocations, or even fragments of cryptographic material if such operations are performed within the same execution context before the vulnerability is triggered. In scenarios where the leaked information does not lead directly to code execution but disrupts subsequent processing logic, it can cause crashes or undefined behavior in the host application, resulting in a denial of service for users attempting to load legitimate module files that interact with the compromised library component. Given that libxmp is widely used by various multimedia applications and music players on multiple platforms including Linux, Windows, and macOS, the attack surface is significant, affecting any user who opens or imports a maliciously crafted P61A file through an application linked against this vulnerable version of the library.
To mitigate this risk, immediate updates to libxmp are required as patches addressing this off-by-one error have been released in versions subsequent to 4.7.4. Developers integrating libxmp into their applications should ensure they are using a patched release and verify that build systems correctly pull these updated dependencies. For organizations unable to update immediately due to compatibility constraints, implementing input validation at the application layer can provide partial protection by rejecting module files with suspiciously large back-reference sizes or malformed structures before they reach the vulnerable depacker function. Additionally, enabling compiler security features such as stack protectors and address sanitizer during development builds can help detect similar issues in future code changes. Security teams should also monitor for any reported incidents of exploitation targeting this specific vulnerability class within their environments, particularly focusing on applications that handle user-supplied audio module files from untrusted sources.
This incident highlights the importance of rigorous bounds checking in legacy format parsers and underscores the relevance of ATT&CK technique T1074, which covers Data Staged or Local Data Staging if an attacker were to use this leak for further reconnaissance within a compromised system context. While primarily classified as an information disclosure vulnerability due to the stack read nature, the potential for destabilizing application state also aligns with aspects of denial-of-service attacks found in ATT&CK technique T1499. Maintaining up-to-date dependencies and employing defense-in-depth strategies including input sanitization are essential practices to prevent exploitation of such low-level memory corruption flaws that persist in widely used open-source libraries handling complex binary formats.