p PatchFirst

PatchFirst · Latest vulnerabilities

mozjs91 vulnerabilities · Page 67

Vulnerabilities published for mozjs91 in the last 30 days: 257. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Clear filters

Vulnerabilities: 1327

  1. CVE-2022-39393

    High · CVSS 8.6EPSS 0.75%No fix published

    Wasmtime vulnerable to data leakage between instances in the pooling allocator

    Wasmtime is a standalone runtime for WebAssembly. Prior to versions 2.0.2 and 1.0.2, there is a bug in Wasmtime's implementation of its pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. This bug has been patched and users should upgrade to Wasmtime 2.0.2 and 1.0.2. Other mitigations include disabling the pooling allocator and disabling the `memory-init-cow`.

    Published Updated
  2. CVE-2022-39392

    Medium · CVSS 5.9EPSS 0.66%No fix published

    Wasmtime vulnerable to out of bounds read/write with zero-memory-pages configuration

    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 thi

    Published Updated
  3. CVE-2022-31169

    Medium · CVSS 5.9EPSS 0.92%No fix published

    Cranelift vulnerable to miscompilation of constant values in division on AArch64

    Wasmtime is a standalone runtime for WebAssembly. There is a bug in Wasmtime's code generator, Cranelift, for AArch64 targets where constant divisors can result in incorrect division results at runtime. This affects Wasmtime prior to version 0.38.2 and Cranelift prior to 0.85.2. This issue only affects the AArch64 platform. Other platforms are not affected. The translation rules for constants did not take into account whether sign or zero-extension should happen which resulted in an incorrect value being placed into a register when a division was encountered. The impact of this bug is that programs executing within the WebAssembly sandbox wou

    Published Updated
  4. CVE-2022-31146

    Medium · CVSS 6.4EPSS 1.25%No fix published

    Use After Free in Wasmtime

    Wasmtime is a standalone runtime for WebAssembly. There is a bug in the Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime then the GC pass will mistakenly think these functions do not have live references to GC'd values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC'd, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37

    Published Updated
  5. CVE-2022-24791

    High · CVSS 8.1EPSS 1.18%No fix published

    Use after free in Wasmtime

    Wasmtime is a standalone JIT-style runtime for WebAssembly, using Cranelift. There is a use after free vulnerability in Wasmtime when both running Wasm that uses externrefs and enabling epoch interruption in Wasmtime. If you are not explicitly enabling epoch interruption (it is disabled by default) then you are not affected. If you are explicitly disabling the Wasm reference types proposal (it is enabled by default) then you are also not affected. The use after free is caused by Cranelift failing to emit stack maps when there are safepoints inside cold blocks. Cold blocks occur when epoch interruption is enabled. Cold blocks are emitted at th

    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →