Is this a vulnerability to move VM-3

thread ‘main’ panicked at ‘index out of bounds: the len is 2 but the index is 2’, /home/user/diem-fuzz/diem-main/language/vm/src/
stack backtrace:
0: rust_begin_unwind
at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/

6: vm::access::ScriptAccess::identifier_at at /home/user/diem-fuzz/diem-main/language/vm/src/
7: vm::access::ScriptAccess::immediate_dependencies::closure at /home/user/diem-fuzz/diem-main/language/vm/src/

17: vm::access::ScriptAccess::immediate_dependencies at /home/user/diem-fuzz/diem-main/language/vm/src/
18: move_vm_runtime::loader::Loader::deserialize_and_verify_script at /home/user/diem-fuzz/diem-main/language/move-vm/runtime/src/
19: move_vm_runtime::loader::Loader::load_script at /home/user/diem-fuzz/diem-main/language/move-vm/runtime/src/
20: move_vm_runtime::runtime::VMRuntime::execute_script at /home/user/diem-fuzz/diem-main/language/move-vm/runtime/src/
21: move_vm_runtime::session::Session::execute_script at /home/user/diem-fuzz/diem-main/language/move-vm/runtime/src/

The input sample is in the github repository

1 Like

Thanks for the reporting @suirui.

First, I noticed that the stack backtrace shown here does not match with the input sample available in the Github link.

Second, the input sample in the Github repo does cause a crash (at an access to a SignatureIndex), The reason for the crash is that a CompiledScriptMut is converted to module (say M) first and then applies the bounds checker to M and then convert M back into a CompiledScript .During the process, a dummy signature is added while converting to M and then removed when converting M back to a script. If we refer to Signature index 0 in other parts of the CompiledScriptMut, the bounds checker will not complain (because M does have a dummy signature at index 0) but that dummy signature is subsequently removed, causing subsequent accesses to overflow.

However, this is not a vulnerability in the Diem setting as we do not allow custom scripts to be executed, and hence, there is no chance for such a script to reach the Move VM. For the same reason, the other two issues you have reported are not vulnerabilities in the Diem network neither. With that said, I am personally very interested in how you get these samples via fuzzing and feel free to ping me if you may share a bit. Thank you!

@suirui: thank you for this high-quality report and for your previous reports! Two notes for future reporting:

  • If you think you have found a vulnerability in Diem, please disclose it privately to This will give us a chance to evaluate the issue, fix it (if it is a vulnerability), and deploy the fix.
  • If you have found a crash bug like this that is not a vulnerability, diem’s GitHub issues page is the best way to ensure that we see and address the issue promptly.

Thanks again and we hope you keep sending these along!

I will also add that if you are using some fuzzing techniques that you would be willing to share, we’d be interested to see if that is something we could incorporate into our existing fuzzing system. Regardless, thanks for letting us know about this problem.

Thank you for your reply. If new problems are found in the follow-up, I will report them to you in these two ways.

在 2021-06-08 12:01:05,“Sam Blackshear via Diem” 写道:

I’m glad to receive your reply. Our project will continue. If we get meaningful results later, we are willing to share with you.

Thanks for this report, @suirui! I believe I fixed the issue causing the panic in [move][vm] Prevent to-module transformation in freeze by modocache · Pull Request #8536 · diem/diem · GitHub. If you’re testing against the main branch of the repository, I believe you’ll be able to confirm the input you provided no longer causes a panic, but instead results in a deserialization error.

Please do keep submitting reports like these!

1 Like