Answer in brief
CVE-2021-43790 records a High severity (CVSS 8.5) vulnerability in Use After Free in lucet-runtime. The current sources do not mark it as known exploited. The current feed maps lucet-runtime (crates.io). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps lucet-runtime (crates.io). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| lucet-runtimecrates.io | >=0.0.0-0 | Not reported |
Published upstream
Nov 30, 2021
Evidence: source:osv:source_dates:source-dates:recordSource modified
Oct 12, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Oct 12, 2026
There is a bug in the main branch of Lucet's lucet-runtime that allows a use-after-free in an Instance object that could result in memory corruption, data race, or other related issues. This bug was introduced early in the development of Lucet and is present in all releases. As a result of this bug, and dependent on the memory backing for the Instance objects, it is possible to trigger a use-after-free when the Instance is dropped. ## Patches Users should upgrade to the main branch of the Lucet repository. Lucet does not provide versioned releases on crates.io. ## Workarounds There is no way to remediate this vulnerability without upgrading. ## Description Lucet uses a "pool" allocator for new WebAssembly instances that are created. This pool allocator manages everything from the linear memory of the wasm instance, the runtime stack for async switching, as well as the memory behind the Instance itself. Instances are referred to via an InstanceHandle type which will, on drop, release the memory backing the Instance back to the pool. When an Instance is dropped, the fields of the Instance are destructed top-to-bottom, however when the alloc: Alloc field is destructed, the memory backing the Instance is released back to the pool before the destructors of the remaining fields are run. If another thread allocates the same memory from the pool while these destructors are still running, a race condition occurs that can lead to use-after-free errors. The bug was corrected by changing how the InstanceHandle destructor operates to ensure that the memory backing an Instance is only returned to the pool once the Instance has been completely destroyed.
Quoted source text, attributed separately from HOL analysis.