🧵How memory works under the hood in the EVM and how this knowledge led me to recently discover a ✨critical vulnerability✨ Oh and if you're new to assembly, don't worry, it's simpler than you think Memory Layout Starting with the basics, Solidity reserves the following 4 32-byte memory slots: 0x00-0x3f (64 bytes): Scratch space for hashing methods We can use this area for temporary memory usage as long as we don't need more than 64 bytes 0x40-0x5f (32 bytes): Free memory pointer This slot keeps a pointer to free memory, i.e. the point beyond which it's safe to write to memory. When we use additional memory, this slot gets updated to point beyond that used memory. It's important that we never overwrite this value or else high level solidity logic may overwrite existing memory unexpectedly 0x60-0x7f (32 bytes): Zero slot This slot is reserved as the initial value for dynamic memory arrays, as such it must always be zero Memory Management Opcodes There are several opcodes that manipulate memory, but for simplicity, we'll focus on the two most common ones: mstore and mload mstore and mload write (store) and read (load) 32 byte values to and from memory, respectively In assembly (yul), mstore takes two inputs, an offset and a (32 byte) value. The value is then placed at the provided offset in memory. Simple, right? mload works about the same, taking just an offset and returning the (32 byte) value at that offset Example Taking what we've learned so far, we can safely write and read to and from memory as follows: The Critical Bug During a recent audit, I came across a simple, yet easy to miss, assembly memory management bug The code worked by manually deriving a storage slot from the hash of a set of parameters, including the caller As commented in the snippet, we expect memory from 0x1c to 0x40 to contain the selector, followed by the caller, followed by a However, even though a is only 96 bits (12 bytes), it overwrites the last 20 bytes of the caller. Since addresses are only 20 bytes long, this overwrites the entire value. This occurs because mstore always writes a full 32 bytes to the provided offset. If a smaller value is provided, the upper bytes will be zeroed such that the full 32 bytes are overwritten (Try testing this out in chisel with !memdump to get a feel for it) As a result of this bug, the storage slot is not derived from the calller, and thus anyone calling this function will write to the same storage slot, bypassing intended authorization logic Fin Let me know if you're feeling ready for an advanced memory management writeup (😈solady style😈)

Solidity just added support for Custom Storage Layouts! This allows specifying that your contract storage starts at a point *other than* zero. However, this still doesn't cover the popular Namespaced Storage Layout that modern contracts often use (EIP-7201). For now, you will need to continue using the verbose (but useful!) Solidity pattern to support custom storage for inherited contracts. Hopefully we get this feature soon!

ERC-7201, namespaced storage, is good but bad at the same time. The solution is to just use the first 9-bytes of the keccak. Stop wasting 32 bytes of precious bytecode space everywhere. No, I don’t think we need an ERC for this. Just code from first-principles.