Stream: git-wasmtime

Topic: wasmtime / PR #14802 Fuzz the component model implements ...

Wasmtime GitHub notifications bot (Oct 19 2026 at 06:29):

jrandolf opened PR #14802 from jrandolf:fuzz-cm-implements to bytecodealliance:main:

implements is the one feature WASI 0.3.1 adopted that's still marked as not fuzzed in docs/stability-wasm-proposals.md, so this is an attempt at closing that gap.

This extends the component_api fuzzer so it can import the host function, and export the guest function, through instances annotated with (implements "wasmtime:fuzz/echo@1.0.0"). The host then defines and looks up the functions through those instances and asserts that is_implements sees the annotation. Both the static and dynamic targets go through the same paths.

Locally this ran for 4×20 minutes (~98k inputs) without finding anything. Once this has been running on OSS-Fuzz for a while, I'd like to follow up with a PR to turn implements on by default.

Wasmtime GitHub notifications bot (Oct 19 2026 at 06:29):

jrandolf requested alexcrichton for a review on PR #14802.

Wasmtime GitHub notifications bot (Oct 19 2026 at 06:29):

jrandolf requested wasmtime-fuzz-reviewers for a review on PR #14802.

Wasmtime GitHub notifications bot (Oct 19 2026 at 06:29):

jrandolf requested wasmtime-core-reviewers for a review on PR #14802.

Wasmtime GitHub notifications bot (Oct 19 2026 at 08:56):

github-actions[bot] added the label fuzzing on PR #14802.

Wasmtime GitHub notifications bot (Oct 19 2026 at 08:56):

github-actions[bot] commented on PR #14802:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Oct 19 2026 at 15:20):

alexcrichton commented on PR #14802:

Thanks for this, although I don't think that this will necessarily count as fuzzing for the implements feature. This is kind of only generating a 2x2 matrix of imports on/off and exports on/off and doesn't really explore much more state space over what could be covered in a unit test itself. That being said we don't have a large amount of fuzzing for components-of-arbitrary-shapes in general. The fuzzer you're modifying here is one which stresses different shapes of values in/out of components, but it does not stress different shapes of components at all.

Given the nature of implements I'm not entirely sure what fuzzing might even look like for the feature within Wasmtime. It'd likely require a relatively substantial new fuzzer or similar or something like that. Overall this isn't something that's really been discussed all that much AFAIK.

Wasmtime GitHub notifications bot (Oct 19 2026 at 20:46):

jrandolf updated PR #14802.

Wasmtime GitHub notifications bot (Oct 20 2026 at 17:06):

alexcrichton commented on PR #14802:

Is the latest commit intended to address the latest comment of mine?

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:29):

jrandolf commented on PR #14802:

Not yet. This is not ready, sorry.

Wasmtime GitHub notifications bot (Oct 20 2026 at 18:39):

jrandolf converted PR #14802 Fuzz the component model implements feature to a draft.

Wasmtime GitHub notifications bot (Oct 21 2026 at 00:26):

jrandolf commented on PR #14802:

Closing in favor of #14895, which adds a fuzzer that generates components of arbitrary shape, as you suggested.

Wasmtime GitHub notifications bot (Oct 21 2026 at 00:26):

:cross_mark: jrandolf closed without merge PR #14802.

Wasmtime GitHub notifications bot (Oct 21 2026 at 00:42):

jrandolf reopened PR #14802 from jrandolf:fuzz-cm-implements to bytecodealliance:main.

Wasmtime GitHub notifications bot (Oct 21 2026 at 02:25):

jrandolf commented on PR #14802:

Thinking about your comment more, I don't think there's a meaningful fuzzer to write for implements.

The spec says attributes are ignored by type checking, and in wasmtime they don't affect compilation, instantiation or calls either. inline.rs copies them for the component's imports and exports, types_builder.rs copies them for the items of component and instance types, and after that they're only returned by ComponentExtern.

The only code that interprets them is ComponentExtern::is_implements, which the named_imports bindings from bindgen! use to find the imports to define, and the named WASI imports are built on those bindings. That's host-side code covered by tests. What this fuzzer found was string matching with canonical names, in is_implements and in Linker lookups, which unit tests cover just as well.

So I'd suggest giving implements the same treatment as the component model: a footnote under Fuzzed saying it's metadata that doesn't affect type checking or execution.

If a fuzzer for arbitrary component shapes would help the component model in general, I'm happy to work on that separately, but the work would be in wasm-smith and it would be more general than just implements since wasm-smith doesn't support components yet.

Wasmtime GitHub notifications bot (Oct 21 2026 at 02:26):

jrandolf edited a comment on PR #14802:

Thinking about your comment more, I don't think there's a meaningful fuzzer to write for implements.

The spec says attributes are ignored by type checking, and in wasmtime they don't affect compilation, instantiation or calls either. inline.rs copies them for the component's imports and exports, types_builder.rs copies them for the items of component and instance types, and after that they're only returned by ComponentExtern.

The only code that interprets them is ComponentExtern::is_implements, which the named_imports bindings from bindgen! use to find the imports to define, and the named WASI imports are built on those bindings. That's host-side code covered by tests. What this fuzzer found was string matching with canonical names, in is_implements and in Linker lookups, which unit tests cover just as well.

So I'd suggest giving implements the same treatment as the component model: a footnote under Fuzzed saying it's metadata that doesn't affect type checking or execution. Alternatively, we can maybe say it's not applicable and replace the fuzzing for implements with exhaustive testing (it has a small state space after all).

If a fuzzer for arbitrary component shapes would help the component model in general, I'm happy to work on that separately, but the work would be in wasm-smith and it would be more general than just implements since wasm-smith doesn't support components yet.

Wasmtime GitHub notifications bot (Oct 21 2026 at 18:11):

alexcrichton commented on PR #14802:

I think that sounds reasonable to me, yeah, and I'd agree with a footnote and otherwise not gating on it.

Having a fuzzer for components would be fantastic yeah. The main blocker in the past has been that it's seems almost non-viable to generate a random component that does anything meaningful beyond trapping. Even with that though just exercising lots of shapes of components through compilation would still be useful I think, and would be a welcome addition to Wasmtime's fuzzing!

Wasmtime GitHub notifications bot (Oct 21 2026 at 18:29):

jrandolf updated PR #14802.

Wasmtime GitHub notifications bot (Oct 21 2026 at 18:44):

jrandolf commented on PR #14802:

Thanks! Closing in favor of #14914, which adds the footnote.

Wasmtime GitHub notifications bot (Oct 21 2026 at 18:44):

:cross_mark: jrandolf closed without merge PR #14802.

Last updated: Oct 31 2026 at 23:03 UTC