wasmtime / issue #13344 GcRuntime::vmctx_gc_heap_data is ... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #13344 GcRuntime::vmctx_gc_heap_data is ...

Wasmtime GitHub notifications bot (May 12 2026 at 22:12):

alexcrichton opened issue #13344:

This is preexisting I think for other collectors, but there's 2 primary ways that this method is UB according to Miri:

This is deriving a pointer from &self which is later mutated through in compiled code. That's UB in Rust because by deriving the pointer from &self you're saying that the contents can't be mutated. This is a playground example showing the UB (top right, Tools -> Miri). The fix for this specific issue is to change this method to &mut self and then have the implementation be NonNull::from(&mut self.vmctx_data).cast()

The second problem is that this struture is stored inline with the CopyingHeap, which means that re-acquiring a mutable pointer to CopyingHeap will actually invalidate the previous pointer returned by this method. This is a playground example of the UB here.

Fixing the latter one is not going to be super easy. I can think a few possible ways:

Every time we return back to wasm re-acquire the pointer and put it back in the VMContext. Probably too slow to work.

Place the VM data behind an indirection (e.g. Box<VMCopyingHeapData> here). The goal is that by using &mut CopyingHeap it doesn't auto-invaildate the vmctx data structures. This alone is not enough, however. Another added fix necessary would be to create the raw pointer at creation of CopyingHeap, and then CopyingHeap itself only accesses the data through that pointer. The end result is sort of like this and models what we do with vm::Instance and its sibling VMContext storage data that comes after it.

I haven't double-checked, but I believe this would all plague the drc/null collectors as well. If you'd like I think it'd be reasonable to fix them all in a subsequent PR.

In terms of detecting all of this, in theory Miri should be able to capture everything here. I think that may mean we're not running much GC-compiled wasms through Miri, which might be a good addition to have? For miri coverage copying this line is probably the easiest. Along those lines rustup run nightly ./ci/miri-wast.sh ./tests/spec_testsuite/struct.wast locally shows a Miri violation which may be related to this, but it's always sort of hard to tell where exactly the miri error comes from due to the mix of pulley and lack of strict provenance...

_Originally posted by @alexcrichton in https://github.com/bytecodealliance/wasmtime/pull/13323#discussion_r3209562532_

Wasmtime GitHub notifications bot (May 12 2026 at 22:12):

alexcrichton added the wasm-proposal:gc label to Issue #13344.

Wasmtime GitHub notifications bot (May 12 2026 at 22:12):

alexcrichton assigned fitzgen to issue #13344.

Wasmtime GitHub notifications bot (May 21 2026 at 18:50):

fitzgen closed issue #13344:

This is preexisting I think for other collectors, but there's 2 primary ways that this method is UB according to Miri:

This is deriving a pointer from &self which is later mutated through in compiled code. That's UB in Rust because by deriving the pointer from &self you're saying that the contents can't be mutated. This is a playground example showing the UB (top right, Tools -> Miri). The fix for this specific issue is to change this method to &mut self and then have the implementation be NonNull::from(&mut self.vmctx_data).cast()

The second problem is that this struture is stored inline with the CopyingHeap, which means that re-acquiring a mutable pointer to CopyingHeap will actually invalidate the previous pointer returned by this method. This is a playground example of the UB here.

Fixing the latter one is not going to be super easy. I can think a few possible ways:

Every time we return back to wasm re-acquire the pointer and put it back in the VMContext. Probably too slow to work.

Place the VM data behind an indirection (e.g. Box<VMCopyingHeapData> here). The goal is that by using &mut CopyingHeap it doesn't auto-invaildate the vmctx data structures. This alone is not enough, however. Another added fix necessary would be to create the raw pointer at creation of CopyingHeap, and then CopyingHeap itself only accesses the data through that pointer. The end result is sort of like this and models what we do with vm::Instance and its sibling VMContext storage data that comes after it.

I haven't double-checked, but I believe this would all plague the drc/null collectors as well. If you'd like I think it'd be reasonable to fix them all in a subsequent PR.

In terms of detecting all of this, in theory Miri should be able to capture everything here. I think that may mean we're not running much GC-compiled wasms through Miri, which might be a good addition to have? For miri coverage copying this line is probably the easiest. Along those lines rustup run nightly ./ci/miri-wast.sh ./tests/spec_testsuite/struct.wast locally shows a Miri violation which may be related to this, but it's always sort of hard to tell where exactly the miri error comes from due to the mix of pulley and lack of strict provenance...

_Originally posted by @alexcrichton in https://github.com/bytecodealliance/wasmtime/pull/13323#discussion_r3209562532_

Last updated: Jun 01 2026 at 09:49 UTC