I've been working on the fuzzing of Wasmtime, a WebAssembly runtime written in Rust. One of the components of Wasmtime is supporting asynchronously running WebAssembly in a way that wasm can be context-switched in-and-out of. This is implemented under the hood with fibers using an in-tree crate called wasmtime-fiber written in a mixture of Rust and assembly.
After writing an initial fuzzer to test out the fiber implementation I quickly ran into errors which all seemed benign but hard to track down. I discovered that asan has intrinsics such as __sanitizer_start_switch_fiber and __sanitizer_finish_switch_fiber to inform the sanitizer runtime about fiber context switches and updated the wasmtime-fiber crate to have calls to those functions. Unfortuantely though this did not fix the purported crashes that I've been seeing.
I've created a sample repository which has a reduced form of this issue, but specifically asan does not detect a situation such as:
A stack is allocated for a fiber with mmap.
Said stack is then used by the fiber.
Said stack is then deallocated after the fiber is finished with munmap.
Later an unrelated part of the project allocates memory with mmap which happens to overlap in the virtual address space where the old stack used to be.
Writes to this new mmap allocation are detected as "stack-buffer-underflow" according to ASAN because it presumably thinks the old stack is still in use.
In the sample above it's an example of using an un-instrumented version of wasmtime-fiber (one that doesn't call __sanitizer_start_switch_fiber) and manually injecting calls to those intrinsics. Despite this, however, the second part of the program which freshly allocates memory and writes to it is detected as a "stack-buffer-underflow" and crashes the program.
Is there away to inform asan that a stack has been entirely deallocate and should no longer be considered allocated memory? Or is there a different way we should be managing stacks in wasmtime-fiber to be compatible with asan's interpretation of fiber stacks?
I've been working on the fuzzing of Wasmtime, a WebAssembly runtime written in Rust. One of the components of Wasmtime is supporting asynchronously running WebAssembly in a way that wasm can be context-switched in-and-out of. This is implemented under the hood with fibers using an in-tree crate called
wasmtime-fiber
written in a mixture of Rust and assembly.After writing an initial fuzzer to test out the fiber implementation I quickly ran into errors which all seemed benign but hard to track down. I discovered that asan has intrinsics such as
__sanitizer_start_switch_fiber
and__sanitizer_finish_switch_fiber
to inform the sanitizer runtime about fiber context switches and updated thewasmtime-fiber
crate to have calls to those functions. Unfortuantely though this did not fix the purported crashes that I've been seeing.I've created a sample repository which has a reduced form of this issue, but specifically asan does not detect a situation such as:
mmap
.munmap
.mmap
which happens to overlap in the virtual address space where the old stack used to be.mmap
allocation are detected as "stack-buffer-underflow" according to ASAN because it presumably thinks the old stack is still in use.In the sample above it's an example of using an un-instrumented version of
wasmtime-fiber
(one that doesn't call__sanitizer_start_switch_fiber
) and manually injecting calls to those intrinsics. Despite this, however, the second part of the program which freshly allocates memory and writes to it is detected as a "stack-buffer-underflow" and crashes the program.Is there away to inform asan that a stack has been entirely deallocate and should no longer be considered allocated memory? Or is there a different way we should be managing stacks in wasmtime-fiber to be compatible with asan's interpretation of fiber stacks?