<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 21:53:56 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-23636 — Invalid drop of partially-initialized instances in wasmtime</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2022-23636</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; bytecodealliance wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is an open source runtime for WebAssembly &amp;amp; WASI. Prior to versions 0.34.1 and 0.33.1, there exists a bug in the pooling instance allocator in Wasmtime&amp;#39;s runtime where a failure to instantiate an instance for a module that defines an `externref` global will result in an invalid drop of a `VMExternRef` via an uninitialized pointer. A number of conditions listed in the GitHub Security Advisory must be true in order for an instance to be vulnerable to this issue. Maintainers believe that the effective impact of this bug is relatively small because the usage of `externref` is still uncommon and without a resource limiter configured on the `Store`, which is not the default configuration, it is only possible to trigger the bug from an error returned by `mprotect` or `VirtualAlloc`. Note that on Linux with the `uffd` feature enabled, it is only possible to trigger the bug from a resource limiter as the call to `mprotect` is skipped. The bug has been fixed in 0.34.1 and 0.33.1 and users are encouraged to upgrade as soon as possible. If it is not possible to upgrade to version 0.34.1 or 0.33.1 of the `wasmtime` crate, it is recommend that support for the reference types proposal be disabled by passing `false` to `Config::wasm_reference_types`. Doing so will prevent modules that use `externref` from being loaded entirely.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; bytecodealliance wasmtime&lt;/p&gt;
&lt;p&gt;Wasmtime is an open source runtime for WebAssembly &amp;amp; WASI. Prior to versions 0.34.1 and 0.33.1, there exists a bug in the pooling instance allocator in Wasmtime&amp;#39;s runtime where a failure to instantiate an instance for a module that defines an `externref` global will result in an invalid drop of a `VMExternRef` via an uninitialized pointer. A number of conditions listed in the GitHub Security Advisory must be true in order for an instance to be vulnerable to this issue. Maintainers believe that the effective impact of this bug is relatively small because the usage of `externref` is still uncommon and without a resource limiter configured on the `Store`, which is not the default configuration, it is only possible to trigger the bug from an error returned by `mprotect` or `VirtualAlloc`. Note that on Linux with the `uffd` feature enabled, it is only possible to trigger the bug from a resource limiter as the call to `mprotect` is skipped. The bug has been fixed in 0.34.1 and 0.33.1 and users are encouraged to upgrade as soon as possible. If it is not possible to upgrade to version 0.34.1 or 0.33.1 of the `wasmtime` crate, it is recommend that support for the reference types proposal be disabled by passing `false` to `Config::wasm_reference_types`. Doing so will prevent modules that use `externref` from being loaded entirely.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2022-23636</guid>
    </item>
    <item>
      <title>GHSA-7f6x-jwh5-m9r4 — Cranelift vulnerable to miscompilation of constant values in division on AArch64</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7f6x-jwh5-m9r4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime, crates.io: cranelift-codegen&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;There was a bug in Wasmtime&amp;#39;s code generator, Cranelift, for AArch64 targets where constant divisors could result in incorrect division results at runtime. 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. For example, a constant 32-bit unsigned divisor of `0xfffffffe` would be incorrectly sign-extended to 64-bits to `0xfffffffffffffffe`. Any kind of division of operands smaller than 64 bits is implemented with a 64-bit division instruction which would then result in an incorrect result because the divisor was larger than expected.&lt;/p&gt;
&lt;p&gt;The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly, but does affect the correctness of guest programs.&lt;/p&gt;
&lt;p&gt;This bug was found with differential fuzzing of Wasmtime against other engines on the AArch64 platform. Fuzzing on AArch64 is not regularly performed at this time and the Wasmtime team is investigating how best to continuously fuzz AArch64 in the same manner as x86_64.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This bug has been patched and users should upgrade to Wasmtime version 0.38.2.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading i…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: wasmtime, crates.io: cranelift-codegen&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;There was a bug in Wasmtime&amp;#39;s code generator, Cranelift, for AArch64 targets where constant divisors could result in incorrect division results at runtime. 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. For example, a constant 32-bit unsigned divisor of `0xfffffffe` would be incorrectly sign-extended to 64-bits to `0xfffffffffffffffe`. Any kind of division of operands smaller than 64 bits is implemented with a 64-bit division instruction which would then result in an incorrect result because the divisor was larger than expected.&lt;/p&gt;
&lt;p&gt;The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly, but does affect the correctness of guest programs.&lt;/p&gt;
&lt;p&gt;This bug was found with differential fuzzing of Wasmtime against other engines on the AArch64 platform. Fuzzing on AArch64 is not regularly performed at this time and the Wasmtime team is investigating how best to continuously fuzz AArch64 in the same manner as x86_64.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This bug has been patched and users should upgrade to Wasmtime version 0.38.2.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7f6x-jwh5-m9r4</guid>
    </item>
  </channel>
</rss>
