bug(forge verify-bytecode) - range end index 18446744073709516997 out of range for slice of length 10855

[blmalone]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (6822860 2024-07-29T00:23:34.055980000Z)

What command(s) is the bug in?

forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig

Operating System

macOS (Apple Silicon)

Describe the bug

I was attempting to verify that this issue has been resolved: #7874 (comment) but when verifying, I ran into a new error. Please see the specific details below:

Steps to reproduce

git clone https://github.com/ethereum-optimism/optimism.git
cd optimism 
git checkout op-contracts/v1.1.0
cd packages/contracts-bedrock
rm -rf lib && forge clean
forge build
forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig

When executing the last command in the steps to reproduce above, the application crashes with the following error:

blaine@blaines-MacBook-Pro contracts-bedrock % forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig
Verifying bytecode for contract SystemConfig at address 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1
The application panicked (crashed).
Message:  range end index 18446744073709516997 out of range for slice of length 10855
Location: crates/verify/src/bytecode.rs:647

This is a bug. Consider reporting it at https://github.com/foundry-rs/foundry

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   1: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   2: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   3: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   4: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   5: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   6: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   7: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   8: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
   9: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  10: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  11: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  12: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  13: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  14: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  15: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  16: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  17: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  18: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  19: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  20: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  21: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>
  22: __mh_execute_header<unknown>
      at <unknown source file>:<unknown line>

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
Run with RUST_BACKTRACE=full to include source snippets.
zsh: abort      forge verify-bytecode 0xba2492e52F45651B60B8B38d4Ea5E2390C64Ffb1 SystemConfig

Possible Cause

I know recently the way constructor args have been determine has changed: #8547
This particular contract doesn't have any constructor args so perhaps the new implementation only works for the happy path when a contract does have constructor args?

[mds1]

@klkvr What do you think about adding some additional tests for this feature? It does feel like we've hit quite a few bugs and some regressions with it, as we've been using it over the past few weeks. I know a few other teams like Maker rely on it also, so just want to increase all of our confidence when trusting it

[mattsse]

panics here

foundry/crates/verify/src/bytecode.rs

Lines 651 to 654 in fdfaafd

	let metadata_len = u16::from_be_bytes([metadata_len[0], metadata_len[1]]);
	// Now discard the metadata from the bytecode
	&bytecode[..bytecode.len() - 2 - metadata_len as usize]

this is create2deployer tx, looks like something is wrong when stripping away the metadata but not very familiar with the details

@yash-atreya does this ring any bells?

[mds1]

To make the metadata stripping more robust you should CBOR-decode it to make sure what you have is actually the encoded metadata. More info here #8139 (comment)

Given that from the panic it seems to be overflowing on &bytecode[..bytecode.len() - 2 - metadata_len as usize], I suspect metadata_len was not actually the metadata length, so the above suggestion should fix that