wasmer
wasmer copied to clipboard
wasmerio
Wasmer cache can throw panic if cache file has been corrupted
https://github.com/wasmerio/wasmer/blob/66c1c00df0704ba2ba59c250ac571586d5010c79/lib/engine-universal/src/artifact.rs#L85-L103
Hello guys, as I can see in code above, you work with string slice without any checks before. As a result this may cause problems in some cases. For example: if we would corrupt file in compiled wasm cache, then this part of code may throw panic, which is not suitable behaviour. I think the best way is to return error in the case.
Hello, thanks for your ticket!
This function is unsafe for this reason as explained in the doc comment: the byte slice is not validated. I think the best way to deal with the problem you're saying is providing an opt-in validation option.
is providing an opt-in validation option.
If you mean - check bytes before calling this method, then it's not the most optimal way. Because then we have to copy some logic from this method and do it before calling it, in order to be sure that it wont throw panic.
Much simple way is if this method returns error in all cases when bytes are in inconsistent state. Even if it's unsafe method =)
I meant a validate: bool argument. You might not want to revalidate an immutable bytes slice after a first validation. Would that satisfy your usecase?
I meant a
validate: boolargument. You might not want to revalidate an immutable bytes slice after a first validation. Would that satisfy your use case.
Yep, if you will use validate = true by default in wasmer functions which uses this method, or propagate validate argument up for all functions which uses this method.
Propagating the option makes sense to me. We're redesigning the API for the next major release, 3.0, at the moment. So we will take this into consideration, thanks for writing the ticket!
If we strive to follow the API guidelines, I think it makes sense to rather expose a deserialize_unchecked(…) method that may panic, and a deserialize(…) method that does checking and returns a Result<…>. The latter may call the former of course, or both call an additional private function that has a validate: bool parameter - depending on what makes more sense for the implementation.
Actually keeping this open because it might get lost in #2925. But it depends on it.
We need to make sure that deserialize that validates the data and never panics.
