Description

Capstone is a disassembly framework. Prior to version 6.0.0-Alpha9, Capstone's public `cs_insn_name()` API forwards caller-supplied instruction IDs directly to the selected architecture backend. Most backends validate the ID before indexing instruction-name tables, but the M68K and RISCV backends have missing or incomplete bounds checks. On a Capstone handle opened for M68K or RISCV, a caller-controlled invalid instruction ID can trigger an out-of-bounds read and crash the process. The demonstrated impact is availability loss in applications or bindings that expose instruction-name lookup to untrusted IDs. No code execution or data disclosure was demonstrated. Version 6.0.0-Alpha9 patches the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.1",
  "pubDate": "2026-08-14T18:17:30.830Z",
  "pubdate": "2026-08-14T18:17:30.830Z",
  "executiveSummary": "An out-of-bounds read vulnerability exists in the Capstone disassembly framework prior to version 6.0.0-Alpha9.\nThe vulnerability resides in the public cs_insn_name() API, which improperly forwards caller-supplied instruction IDs directly to architecture-specific backends without adequate validation.\nSpecifically, the M68K and RISCV backends lack complete bounds checks when indexing internal instruction-name tables.\nThe primary impact of this vulnerability is availability loss, manifesting as a process crash when an application or language binding passes a malicious or out-of-bounds instruction ID to the affected API.\nWhile the impact is restricted to denial of service through application termination, attackers capable of supplying untrusted instruction IDs can systematically crash dependent services.\nNo remote code execution or unauthorized data disclosure capabilities have been demonstrated under current exploitation vectors.\nRemediation requires upgrading the Capstone framework to version 6.0.0-Alpha9 or later, where appropriate bounds checking is implemented within the M68K and RISCV architecture backends.",
  "technicalDetails": "The root cause of the vulnerability is the absence of comprehensive input validation within the M68K and RISCV architecture backends of the Capstone disassembly framework.\nWhen a client application invokes the public API function cs_insn_name(), the framework accepts a Capstone handle and an instruction ID parameter provided by the caller.\nWhile the core API and most architecture backends perform preliminary bounds checking before accessing instruction-name mapping tables, the M68K and RISCV backends fail to adequately verify whether the supplied instruction ID falls within the valid range of defined indices.\nConsequently, an attacker who controls or influences the instruction ID parameter passed to cs_insn_name() can supply an arbitrarily large or negative integer value.\nDuring execution, the vulnerable backend uses this unvalidated integer as an index to access internal static arrays or tables containing instruction mnemonics.\nThis direct memory indexing operation results in an out-of-bounds read, attempting to dereference memory addresses outside the intended boundaries of the instruction-name table.\nDepending on the memory layout and the specific runtime environment, this memory access violation triggers a segmentation fault or a similar memory protection exception, abruptly terminating the host process and leading to a denial of service.\nBecause the vulnerability is triggered via library function calls, exploitation requirements depend on how applications or language bindings expose the cs_insn_name() interface to untrusted inputs.\nIf an application forwards external data directly into the instruction-name lookup routine without prior sanitization, it becomes susceptible to crash induction.\nThe affected components are the M68K and RISCV backends integrated within Capstone versions prior to 6.0.0-Alpha9.\nThere are no authentication, network exposure, or elevated privilege requirements inherent to the vulnerability itself, as the fault manifests entirely within local API processing logic when processing malformed arguments."
}