Skip to content

Use After Free in lucet

High severity GitHub Reviewed Published Nov 29, 2021 in bytecodealliance/lucet • Updated Feb 1, 2023

Package

cargo lucet-runtime (Rust)

Affected versions

<= 0.6.1

Patched versions

None

Description

Impact

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.

This security advisory has been assigned CVE-2021-43790.

For more information

If you have any questions or comments about this advisory:

References

@pchickey pchickey published to bytecodealliance/lucet Nov 29, 2021
Published by the National Vulnerability Database Nov 30, 2021
Reviewed Nov 30, 2021
Published to the GitHub Advisory Database Nov 30, 2021
Last updated Feb 1, 2023

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

EPSS score

0.765%
(81st percentile)

Weaknesses

CVE ID

CVE-2021-43790

GHSA ID

GHSA-hf79-8hjp-rrvq

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.