Vyper's `extract32` can ready dirty memory

Summary

When using the built-in extract32(b, start), if the start index provided has for side effect to update b, the byte array to extract 32 bytes from, it could be that some dirty memory is read and returned by extract32.

As of v0.4.0 (specifically, commit https://github.com/vyperlang/vyper/commit/3d9c537142fb99b2672f21e2057f5f202cde194f), the compiler will panic instead of generating bytecode.

Details

Before evaluating start, the function Extract32.build_IR caches only:

• The pointer in memory/storage to b: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L916-L918
• The length of b: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L920-L922

but do not cache the actual content of b. This means that if the evaluation of start changes b's content and length, an outdated length will be used with the new content when extracting 32 bytes from b.

PoC

Calling the function foo of the following contract returns b'uuuuuuuuuuuuuuuuuuuuuuuuuuu\x00\x00789' meaning that extract32 accessed some dirty memory.

var:Bytes[96]

@internal
def bar() -> uint256:
    self.var = b'uuuuuuuuuuuuuuuuuuuuuuuuuuuuuu'
    self.var = b''
    return 3

@external
def foo() -> bytes32:
    self.var = b'abcdefghijklmnopqrstuvwxyz123456789'
    return extract32(self.var, self.bar(), output_type=bytes32)
    # returns b'uuuuuuuuuuuuuuuuuuuuuuuuuuu\x00\x00789'

Impact

For contracts that are affected, it means that calling extract32 returns dirty memory bytes instead of some expected output.