Capstone vulnerabilities

Capstone is a disassembly framework. In 6.0.0-Alpha9 and earlier, the sh_disassemble() function in arch/SH/SHDisassembler.c computes an idx value from a raw 16-bit instruction without ensuring it is within the active mode-specific decode[] function-pointer table. An application using CS_ARCH_SH with CS_MODE_SH2A or CS_MODE_SH4A and CS_MODE_SHFPU can pass crafted bytecode through cs_disasm_iter() or cs_disasm(), causing the decode[idx] test to read outside the table and terminate the process with a segmentation fault. No code execution or information disclosure was demonstrated. This issue is fixed in version 6.0.0-Alpha10.

Capstone is a disassembly framework. In 6.0.0-Alpha9 and earlier, SH floating-point decoders call set_reg() without checking the operands[] array size, leading to a 4-byte heap buffer overflow. This can crash the process or enable code execution. Fixed in 6.0.0-Alpha10.

In Capstone before version 6.0.0-Alpha9, the public cs_insn_name() API forwards instruction IDs to M68K and RISCV backends without proper bounds checks, potentially causing an out-of-bounds read and process crash.

Capstone is a disassembly framework. Prior to version 6.0.0-Alpha9, Capstone's WebAssembly backend accepts attacker-controlled raw WASM instruction bytes through the public `cs_disasm()` and `cs_disasm_iter()` APIs. For a large but well-formed `br_table` instruction, the WASM decoder accumulates the immediate length in a wider local variable but returns it through a `uint16_t` instruction-size path. When the encoded instruction length is exactly 65,536 bytes, the size wraps to zero and `cs_disasm()` can repeatedly decode the same instruction without advancing. For larger lengths, `cs_disasm_iter()` advances into the middle of the `br_table` payload and decodes target bytes as subsequent instructions. This is an availability and parser-integrity issue. Version 6.0.0-Alpha9 patches the issue.

Vulnerability in Capstone before versions 6.0.0-Alpha8 and 5.0.8. In builds with `-DCAPSTONE_X86_REDUCE`, disassembling 3DNow! opcodes (`0F 0F`) causes a null pointer dereference in `modRMRequired()` and `decode()`, allowing a remote attacker to crash the application.