Panic in table.init
#8281
Labels
bug
Incorrect behavior in the current implementation that needs fixing
Comments
ShinWonho
added
the
bug
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 2, 2024
This commit fixes an accidental issue introduced in bytecodealliance#8018 where using an element segment which had been dropped with an `externref` table would cause a panic. The panic happened due to an assertion that tables are being used with the right type of item and that was being mismatched. The underlying issue was that dropped element segments are modeled as an empty element segment but the empty element segment was using the "functions" encoding as opposed to the "expressions" encoding. This meant that code later assumed that due to the use of functions the table must be a table-of-functions, but this was not correct for externref-based tables. The fix in this commit is to instead model the encoding as an "expressions" list which means that the table type is dispatched on to call the appropriate initializer. There is no memory safety issue with this mistake as the assertion was specifically targetted at preventing memory safety. This does, however, enable any WebAssembly module to panic a host. Closes bytecodealliance#8281
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 2, 2024
This commit fixes an accidental issue introduced in bytecodealliance#8018 where using an element segment which had been dropped with an `externref` table would cause a panic. The panic happened due to an assertion that tables are being used with the right type of item and that was being mismatched. The underlying issue was that dropped element segments are modeled as an empty element segment but the empty element segment was using the "functions" encoding as opposed to the "expressions" encoding. This meant that code later assumed that due to the use of functions the table must be a table-of-functions, but this was not correct for externref-based tables. The fix in this commit is to instead model the encoding as an "expressions" list which means that the table type is dispatched on to call the appropriate initializer. There is no memory safety issue with this mistake as the assertion was specifically targetted at preventing memory safety. This does, however, enable any WebAssembly module to panic a host. Closes bytecodealliance#8281
|
Thanks for the report! Do you perhaps have more detail on how this was discovered? For example is this a reduced module? Or perhaps a fuzz-generated test case? Also as per our documentation this is a security issue so we'll be issuing a CVE and a 19.0.1 release for this. If you discover more issues like this we'd be grateful if you'd contact us privately so we can coordinate this, thanks! |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 2, 2024
This commit fixes an accidental issue introduced in bytecodealliance#8018 where using an element segment which had been dropped with an `externref` table would cause a panic. The panic happened due to an assertion that tables are being used with the right type of item and that was being mismatched. The underlying issue was that dropped element segments are modeled as an empty element segment but the empty element segment was using the "functions" encoding as opposed to the "expressions" encoding. This meant that code later assumed that due to the use of functions the table must be a table-of-functions, but this was not correct for externref-based tables. The fix in this commit is to instead model the encoding as an "expressions" list which means that the table type is dispatched on to call the appropriate initializer. There is no memory safety issue with this mistake as the assertion was specifically targetted at preventing memory safety. This does, however, enable any WebAssembly module to panic a host. Closes bytecodealliance#8281
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 2, 2024
This commit fixes an accidental issue introduced in #8018 where using an element segment which had been dropped with an `externref` table would cause a panic. The panic happened due to an assertion that tables are being used with the right type of item and that was being mismatched. The underlying issue was that dropped element segments are modeled as an empty element segment but the empty element segment was using the "functions" encoding as opposed to the "expressions" encoding. This meant that code later assumed that due to the use of functions the table must be a table-of-functions, but this was not correct for externref-based tables. The fix in this commit is to instead model the encoding as an "expressions" list which means that the table type is dispatched on to call the appropriate initializer. There is no memory safety issue with this mistake as the assertion was specifically targetted at preventing memory safety. This does, however, enable any WebAssembly module to panic a host. Closes #8281
alexcrichton
added a commit
that referenced
this issue
Apr 2, 2024
This commit fixes an accidental issue introduced in #8018 where using an element segment which had been dropped with an `externref` table would cause a panic. The panic happened due to an assertion that tables are being used with the right type of item and that was being mismatched. The underlying issue was that dropped element segments are modeled as an empty element segment but the empty element segment was using the "functions" encoding as opposed to the "expressions" encoding. This meant that code later assumed that due to the use of functions the table must be a table-of-functions, but this was not correct for externref-based tables. The fix in this commit is to instead model the encoding as an "expressions" list which means that the table type is dispatched on to call the appropriate initializer. There is no memory safety issue with this mistake as the assertion was specifically targetted at preventing memory safety. This does, however, enable any WebAssembly module to panic a host. Closes #8281
|
We are in progress of implementing a wasm fuzzer based on SpecTec. Currently, it generates short wasm programs by a simple syntax-driven approach. We performed differential testing with the latest wasmtime and previous versions, and luckily found the bug. We reduced the buggy program manually as the generated program was simple. |
|
Nice! If y'all need any help with fuzzing or such we're happy to talk as well. And thank you for fuzzing, we very much appreciate it! |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Test Case
Steps to Reproduce
Expected Results
terminate normally
Actual Results
Versions and Environment
Wasmtime version or commit: 19.0.0
Operating system: macOS Ventura 13.6.6
Architecture: x86_64
The text was updated successfully, but these errors were encountered: