Stream: git-wasmtime

Topic: wasmtime / PR #2408 Fix a use-after-free of trampoline code

Wasmtime GitHub notifications bot (Nov 12 2020 at 22:13):

alexcrichton opened PR #2408 from fix-use-after-free-trampoline to main:

This commit fixes an issue with wasmtime where it was possible for a
trampoline from one module to get used for another module after it was
freed. This issue arises because we register a module's native
trampolines before it's fully instantiated, which is a fallible
process. Some fallibility is predictable, such as import type
mismatches, but other fallibility is less predictable, such as failure
to allocate a linear memory.

The problem happened when a module was registered with a Store,
retaining information about its trampolines, but then instantiation
failed and the module's code was never persisted within the Store.
Unlike as documented in #2374 the Module inside an Instance is not
the primary way to hold on to a module's code, but rather the
Arc<ModuleCode> is persisted within the global frame information off
on the side. This persistence only made its way into the store through
the Box<Any> field of InstanceHandle, but that's never made if
instantiation fails during import matching.

The fix here is to build on the refactoring of #2407 to not store module
code in frame information but rather explicitly in the Store.
Registration is now deferred until just-before an instance handle is
created, and during module registration we insert the Arc<ModuleCode>
into a set stored within the Store.

Wasmtime GitHub notifications bot (Nov 12 2020 at 22:22):

alexcrichton updated PR #2408 from fix-use-after-free-trampoline to main:

This commit fixes an issue with wasmtime where it was possible for a
trampoline from one module to get used for another module after it was
freed. This issue arises because we register a module's native
trampolines before it's fully instantiated, which is a fallible
process. Some fallibility is predictable, such as import type
mismatches, but other fallibility is less predictable, such as failure
to allocate a linear memory.

The problem happened when a module was registered with a Store,
retaining information about its trampolines, but then instantiation
failed and the module's code was never persisted within the Store.
Unlike as documented in #2374 the Module inside an Instance is not
the primary way to hold on to a module's code, but rather the
Arc<ModuleCode> is persisted within the global frame information off
on the side. This persistence only made its way into the store through
the Box<Any> field of InstanceHandle, but that's never made if
instantiation fails during import matching.

The fix here is to build on the refactoring of #2407 to not store module
code in frame information but rather explicitly in the Store.
Registration is now deferred until just-before an instance handle is
created, and during module registration we insert the Arc<ModuleCode>
into a set stored within the Store.

Wasmtime GitHub notifications bot (Nov 12 2020 at 22:33):

alexcrichton updated PR #2408 from fix-use-after-free-trampoline to main:

This commit fixes an issue with wasmtime where it was possible for a
trampoline from one module to get used for another module after it was
freed. This issue arises because we register a module's native
trampolines before it's fully instantiated, which is a fallible
process. Some fallibility is predictable, such as import type
mismatches, but other fallibility is less predictable, such as failure
to allocate a linear memory.

The problem happened when a module was registered with a Store,
retaining information about its trampolines, but then instantiation
failed and the module's code was never persisted within the Store.
Unlike as documented in #2374 the Module inside an Instance is not
the primary way to hold on to a module's code, but rather the
Arc<ModuleCode> is persisted within the global frame information off
on the side. This persistence only made its way into the store through
the Box<Any> field of InstanceHandle, but that's never made if
instantiation fails during import matching.

The fix here is to build on the refactoring of #2407 to not store module
code in frame information but rather explicitly in the Store.
Registration is now deferred until just-before an instance handle is
created, and during module registration we insert the Arc<ModuleCode>
into a set stored within the Store.

Wasmtime GitHub notifications bot (Nov 17 2020 at 00:35):

fitzgen merged PR #2408.

Last updated: Dec 23 2024 at 13:07 UTC