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

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.

Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from version 0.26.0 and before version 0.30.0 is affected by a memory unsoundness vulnerability. There was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. To trigger this bug, Wasmtime needs to be running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where there are no live references at this safepoint, and there is a safepoint with live references earlier in this frame's function. Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from earlier in the function instead of the empty safepoint. This would result in Wasmtime treating arbitrary stack slots as `externref`s that needed to be rooted for GC. At the *next* GC, it would be determined that nothing was referencing these bogus `externref`s (because nothing could ever reference them, because they are not really `externref`s) and then Wasmtime would deallocate them and run `<ExternRef as Drop>::drop` on them. This results in a free of memory that is not necessarily on the heap (and shouldn't be freed at this moment even if it was), as well as potential out-of-bounds reads and writes. Even though support for `externref`s (via the reference types proposal) is enabled by default, unless you are creating non-null `externref`s in your host code or explicitly triggering GCs, you cannot be affected by this bug. We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime at this time, you can avoid this bug by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types`.

Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, there is a bug in Wasmtime's implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration, the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtime's default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocator's configuration would not create an appropriate virtual memory mapping for this meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator. This bug is not applicable with the default settings of the `wasmtime` crate. This bug can only be triggered by setting `InstanceLimits::memory_pages` to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm modules produced by all current toolchains are highly likely to use linear memory, so it's expected to be unlikely that this configuration is set to zero by any production embedding of Wasmtime. This bug has been patched and users should upgrade to Wasmtime 2.0.2. This bug can be worked around by increasing the `memory_pages` allotment when configuring the pooling allocator to a value greater than zero. If an embedding wishes to still prevent memory from actually being used then the `Store::limiter` method can be used to dynamically disallow growth of memory beyond 0 bytes large. Note that the default `memory_pages` value is greater than zero.

Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, there is a bug in Wasmtime's C API implementation where the definition of the `wasmtime_trap_code` does not match its declared signature in the `wasmtime/trap.h` header file. This discrepancy causes the function implementation to perform a 4-byte write into a 1-byte buffer provided by the caller. This can lead to three zero bytes being written beyond the 1-byte location provided by the caller. This bug has been patched and users should upgrade to Wasmtime 2.0.2. This bug can be worked around by providing a 4-byte buffer casted to a 1-byte buffer when calling `wasmtime_trap_code`. Users of the `wasmtime` crate are not affected by this issue, only users of the C API function `wasmtime_trap_code` are affected.

wasmtime is a fast and secure runtime for WebAssembly. In affected versions wasmtime's code generator, Cranelift, has a bug on x86_64 targets where address-mode computation mistakenly would calculate a 35-bit effective address instead of WebAssembly's defined 33-bit effective address. This bug means that, with default codegen settings, a wasm-controlled load/store operation could read/write addresses up to 35 bits away from the base of linear memory. Due to this bug, however, addresses up to `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` bytes away from the base of linear memory are possible from guest code. This means that the virtual memory 6G away from the base of linear memory up to ~34G away can be read/written by a malicious module. A guest module can, without the knowledge of the embedder, read/write memory in this region. The memory may belong to other WebAssembly instances when using the pooling allocator, for example. Affected embedders are recommended to analyze preexisting wasm modules to see if they're affected by the incorrect codegen rules and possibly correlate that with an anomalous number of traps during historical execution to locate possibly suspicious modules. The specific bug in Cranelift's x86_64 backend is that a WebAssembly address which is left-shifted by a constant amount from 1 to 3 will get folded into x86_64's addressing modes which perform shifts. For example `(i32.load (i32.shl (local.get 0) (i32.const 3)))` loads from the WebAssembly address `$local0 << 3`. When translated to Cranelift the `$local0 << 3` computation, a 32-bit value, is zero-extended to a 64-bit value and then added to the base address of linear memory. Cranelift would generate an instruction of the form `movl (%base, %local0, 8), %dst` which calculates `%base + %local0 << 3`. The bug here, however, is that the address computation happens with 64-bit values, where the `$local0 << 3` computation was supposed to be truncated to a a 32-bit value. This means that `%local0`, which can use up to 32-bits for an address, gets 3 extra bits of address space to be accessible via this `movl` instruction. The fix in Cranelift is to remove the erroneous lowering rules in the backend which handle these zero-extended expression. The above example is then translated to `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` which correctly truncates the intermediate computation of `%local0 << 3` to 32-bits inside the `%temp` register which is then added to the `%base` value. Wasmtime version 4.0.1, 5.0.1, and 6.0.1 have been released and have all been patched to no longer contain the erroneous lowering rules. While updating Wasmtime is recommended, there are a number of possible workarounds that embedders can employ to mitigate this issue if updating is not possible. Note that none of these workarounds are on-by-default and require explicit configuration: 1. The `Config::static_memory_maximum_size(0)` option can be used to force all accesses to linear memory to be explicitly bounds-checked. This will perform a bounds check separately from the address-mode computation which correctly calculates the effective address of a load/store. Note that this can have a large impact on the execution performance of WebAssembly modules. 2. The `Config::static_memory_guard_size(1 << 36)` option can be used to greatly increase the guard pages placed after linear memory. This will guarantee that memory accesses up-to-34G away are guaranteed to be semantically correct by reserving unmapped memory for the instance. Note that this reserves a very large amount of virtual memory per-instances and can greatly reduce the maximum number of concurrent instances being run. 3. If using a non-x86_64 host is possible, then that will also work around this bug. This bug does not affect Wasmtime's or Cranelift's AArch64 backend, for example.

Improper validation of DRAM addresses in SMU may allow an attacker to overwrite sensitive memory locations within the ASP potentially resulting in a denial of service.

ImageSharp is a 2D graphics API. An Out-of-bounds Write vulnerability has been found in the ImageSharp gif decoder, allowing attackers to cause a crash using a specially crafted gif. This can potentially lead to denial of service. All users are advised to upgrade to v3.1.5 or v2.1.9.

Multiple memory corruption issues were addressed with improved input validation. This issue is fixed in macOS Ventura 13.4, iOS 16.5 and iPadOS 16.5. Multiple issues in libxml2.

Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the entrys parameter at ip/goform/addressNat.

Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the mitInterface parameter in ip/goform/RouteStatic

Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the page parameter at ip/goform/NatStaticSetting.

Tenda M3 V1.0.0.12 was discovered to contain a stack overflow via the function formSetAPCfg.

Tenda AX1806 v1.0.0.1 was discovered to contain a stack overflow via the list parameter in the function formSetQosBand.

Heap-based buffer overflow vulnerability in the SonicOS IPSec VPN allows an unauthenticated remote attacker to cause Denial of Service (DoS).

An issue was discovered in GNU LibreDWG 0.7 and 0.7.1645. There is a heap-based buffer overflow in the function dwg_decode_eed_data at decode.c for the z dimension.

The video framework has an out-of-bounds memory read/write vulnerability. Successful exploitation of this vulnerability may affect system availability.

DWRCC in SolarWinds DameWare Mini Remote Control 10.0 x64 has a Buffer Overflow associated with the size field for the machine name.

UltraVNC revision 1211 has a stack buffer overflow vulnerability in VNC server code inside file transfer request handler, which can result in Denial of Service (DoS). This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.

An issue was discovered in Samsung Mobile Processor, Wearable Processor, Automotive Processor, and Modem (Exynos 9810, 9610, 9820, 980, 850, 1080, 2100, 2200, 1280, 1380, 1330, 9110, W920, Modem 5123, Modem 5300, and Auto T5123). Improper handling of a length parameter inconsistency can cause abnormal termination of a mobile phone. This occurs in the RLC task and RLC module.

Memory overwriting vulnerability in the security module. Successful exploitation of this vulnerability may affect availability.

Veilid before 0.1.9 does not check the size of uncompressed data during decompression upon an envelope receipt, which allows remote attackers to cause a denial of service (out-of-memory abort) via crafted packet data, as exploited in the wild in August 2023.

Tenda AX3 v16.03.12.11 has a stack buffer overflow vulnerability detected at function form_fast_setting_wifi_set. This vulnerability allows attackers to cause a Denial of Service (DoS) via the ssid parameter.

A heap buffer overflow in r_sleb128 function in radare2 5.4.2 and 5.4.0.

Tenda A18 V15.13.07.09 was discovered to contain a stack overflow via the rule_info parameter in the formAddMacfilterRule function.

Tenda AC8V4 V16.03.34.06 was discovered to contain a stack overflow via the time parameter in the sscanf function.

eprosima Fast DDS is a C++ implementation of the Data Distribution Service standard of the Object Management Group. Prior to versions 2.11.1, 2.10.2, 2.9.2, and 2.6.6, even after the fix at commit 3492270, malformed `PID_PROPERTY_LIST` parameters cause heap overflow at a different program counter. This can remotely crash any Fast-DDS process. Versions 2.11.1, 2.10.2, 2.9.2, and 2.6.6 contain a patch for this issue.

In ElementaryStreamQueue::dequeueAccessUnitMPEG4Video of ESQueue.cpp, there is a possible infinite loop leading to resource exhaustion due to an incorrect bounds check. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation.

async-sockets-cpp through 0.3.1 has a stack-based buffer overflow in ReceiveFrom and Receive in udpsocket.hpp when processing malformed UDP packets.

Tenda A18 V15.13.07.09 was discovered to contain a stack overflow via the security parameter in the formWifiBasicSet function.

An Heap-based Buffer Overflow in RT-Labs P-Net version 1.0.1 or earlier allows an attacker to induce a crash in IO devices that use the library by sending a malicious RPC packet.

Tenda A18 V15.13.07.09 was discovered to contain a stack overflow via the wpapsk_crypto2_4g parameter in the fromSetWirelessRepeat function.

PTC’s KEPServerEX Versions 6.0 to 6.14.263 are vulnerable to being made to read a recursively defined object that leads to uncontrolled resource consumption. KEPServerEX uses OPC UA, a protocol which defines various object types that can be nested to create complex arrays. It does not implement a check to see if such an object is recursively defined, so an attack could send a maliciously created message that the decoder would try to decode until the stack overflowed and the device crashed.

A Stack-based buffer overflow in the Mobile Management Entity (MME) of Magma versions <= 1.8.0 (fixed in v1.9 commit 08472ba98b8321f802e95f5622fa90fec2dea486) allows remote attackers to crash the MME with an unauthenticated cellphone by sending a NAS packet containing an oversized `Emergency Number List` Information Element.

A flaw was found in Samba's libldb. Multiple, consecutive leading spaces in an LDAP attribute can lead to an out-of-bounds memory write, leading to a crash of the LDAP server process handling the request. The highest threat from this vulnerability is to system availability.

CMysten Labs Sui blockchain v1.2.0 was discovered to contain a stack overflow via the component /spec/openrpc.json.

H3C Magic B1STW B1STV100R012 was discovered to contain a stack overflow via the function SetAPInfoById. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request.

A stack overflow in the UpdateSnat function of H3C Magic B1STV100R012 allows attackers to cause a Denial of Service (DoS) via a crafted POST request.

Asus RT-N10LX Router v2.0.0.39 was discovered to contain a stack overflow via the mac parameter at /start-apply.html. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

An issue was discovered sojo thru 1.1.1 allows attackers to cause a denial of service or other unspecified impacts via crafted object that uses cyclic dependencies.

A stack overflow in the Edit_BasicSSID function of H3C Magic B1STV100R012 allows attackers to cause a Denial of Service (DoS) via a crafted POST request.

An issue was discovered mjson thru 1.4.1 allows attackers to cause a denial of service or other unspecified impacts via crafted object that uses cyclic dependencies.

Stack-based buffer overflow vulnerability in the SonicOS HTTP server allows an authenticated remote attacker to cause Denial of Service (DoS) via sscanf function.

eprosima Fast DDS is a C++ implementation of the Data Distribution Service standard of the Object Management Group. Prior to versions 2.14.0, 2.13.4, 2.12.3, 2.10.4, and 2.6.8, manipulated DATA Submessage can cause a heap overflow error in the Fast-DDS process, causing the process to be terminated remotely. Additionally, the payload_size in the DATA Submessage packet is declared as uint32_t. When a negative number, such as -1, is input into this variable, it results in an Integer Overflow (for example, -1 gets converted to 0xFFFFFFFF). This eventually leads to a heap-buffer-overflow, causing the program to terminate. Versions 2.14.0, 2.13.4, 2.12.3, 2.10.4, and 2.6.8 contain a fix for this issue.

An issue was discovered jjson thru 0.1.7 allows attackers to cause a denial of service or other unspecified impacts via crafted object that uses cyclic dependencies.

An out-of-bounds write vulnerability on windows operating systems causes the Ivanti AntiVirus Product to crash. Update to Ivanti AV Product version 7.9.1.285 or above.

Buffer underflow in some Intel(R) PCM software before version 202307 may allow an unauthenticated user to potentially enable denial of service via network access.

An issue was discovered jtidy thru r938 allows attackers to cause a denial of service or other unspecified impacts via crafted object that uses cyclic dependencies.

LBT T300-T390 v2.2.1.8 were discovered to contain a stack overflow via the ApCliSsid parameter in the generate_conf_router function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request.