WebAssembly Micro Runtime vulnerable to a segmentation fault in v128.store instruction

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to version 2.4.4, WAMR is susceptible to a segmentation fault in v128.store instruction. This issue has been patched in version 2.4.4.

WebAssembly Micro Runtime frame_offset_bottom array bounds overflow in fast Interpreter mode when handling GET_GLOBAL(I32) followed by if opcode

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to version 2.4.4, an out-of-bounds array access issue exists in WAMR's fast interpreter mode during WASM bytecode loading. When frame_ref_bottom and frame_offset_bottom arrays are at capacity and a GET_GLOBAL(I32) opcode is encountered, frame_ref_bottom is expanded but frame_offset_bottom may not be. If this is immediately followed by an if opcode that triggers preserve_local_for_block, the function traverses arrays using stack_cell_num as the upper bound, causing out-of-bounds access to frame_offset_bottom since it wasn't expanded to match the increased stack_cell_num. This issue has been patched in version 2.4.4.

wasm-micro-runtime (aka WebAssembly Micro Runtime or WAMR) 06df58f is vulnerable to NULL Pointer Dereference in function `block_type_get_result_types.

WebAssembly Micro Runtime's `--addr-pool` option allows all IPv4 addresses when subnet mask is not specified

The WebAssembly Micro Runtime's (WAMR) iwasm package is the executable binary built with WAMR VMcore which supports WebAssembly System Interface (WASI) and command line interface. In versions 2.4.0 and below, iwasm uses --addr-pool with an IPv4 address that lacks a subnet mask, allowing the system to accept all IP addresses. This can unintentionally expose the service to all incoming connections and bypass intended access restrictions. Services relying on --addr-pool for restricting access by IP may unintentionally become open to all external connections. This may lead to unauthorized access in production deployments, especially when users assume that specifying an IP without a subnet mask implies a default secure configuration. This is fixed in version 2.4.1.

WAMR runtime hangs or crashes with large memory.fill addresses in LLVM-JIT mode

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. In WAMR versions prior to 2.4.2, when running in LLVM-JIT mode, the runtime cannot exit normally when executing WebAssembly programs containing a memory.fill instruction where the first operand (memory address pointer) is greater than or equal to 2147483648 bytes (2GiB). This causes the runtime to hang in release builds or crash in debug builds due to accessing an invalid pointer. The issue does not occur in FAST-JIT mode or other runtime tools. This has been fixed in version 2.4.2.

iwasm vulnerable to filesystem sandbox escape with symlink when using uvwasi feature

The WebAssembly Micro Runtime's (WAMR) iwasm package is the executable binary built with WAMR VMcore which supports WebAssembly System Interface (WASI) and command line interface. Anyone running WAMR up to and including version 2.2.0 or WAMR built with libc-uvwasi on Windows is affected by a symlink following vulnerability. On WAMR running in Windows, creating a symlink pointing outside of the preopened directory and subsequently opening it with create flag will create a file on host outside of the sandbox. If the symlink points to an existing host file, it's also possible to open it and read its content. Version 2.3.0 fixes the issue.

A heap buffer overflow vulnerability was discovered in Bytecode Alliance wasm-micro-runtime v2.0.0 which allows a remote attacker to cause at least a denial of service via the "wasm_loader_check_br" function in core/iwasm/interpreter/wasm_loader.c.

An out-of-bound memory read vulnerability was discovered in Bytecode Alliance wasm-micro-runtime v2.0.0 which allows a remote attacker to cause a denial of service via the "block_type_get_arity" function in core/iwasm/interpreter/wasm.h.

An heap overflow vulnerability was discovered in Bytecode alliance wasm-micro-runtime v.1.2.3 allows a remote attacker to cause a denial of service via the wasm_loader_prepare_bytecode function in core/iwasm/interpreter/wasm_loader.c.

Bytecode Alliance wasm-micro-runtime (aka WebAssembly Micro Runtime or WAMR) before 1.3.0 can have an "double free or corruption" error for a valid WebAssembly module because push_pop_frame_ref_offset is mishandled.

An issue in bytecodealliance wasm-micro-runtime before v.b3f728c and fixed in commit 06df58f allows a remote attacker to escalate privileges via a crafted file to the check_was_abi_compatibility function.