I launched an ERC20 contract via the Open Zeppelin a few months ago. Recently, there was a yellow triangle with an error by the contract on Etherscan that said there was a medium security vulnerability. The Bug Name is: AbiReencodingHeadOverflowWithStaticArrayCleanup. The problem I am running into is I have no idea whether this is solvable or how to proceed. The documentation for the bug is detailed at level of technical depth far beyond my knowledge base. As is this article on the bug, and I am not sure whether there is any recommended or necessary action for fixing it. Any advice or suggestions would be greatly appreciated. Thanks!
Hi,
This seems like a question for the etherscan team, or you could include more details, like your contract, or a link to its etherscan page.
Hi @JulissaDantes thanks for the reply. Sure, here is the contract on Etherscan. The reason I asked here, rather than Etherscan is because I used the Open Zepplin Wizard to create the contract. So, if there is a bug in the contract, it may also apply to other contracts launched with the Wizard software.
I'm having the same bug notification name, AbiReencodingHeadOverflowWithStaticArrayCleanup, did you find more about that?
Hi - no. I haven't found out anything more about this bug. It seems like a potential bug with the Open Zeppelin ERC-20 contract, but I have no idea where to start in resolving it. I'm not sure under what circumstances or whether the bug can be exploited either.
Just wanted to follow up on this. I still haven't found a fix for this. I found another contract with the same bug.
This post focuses on the first (medium-severity) issue, however it seems this might be a product of needed upgrades for the Open Zepplin contract that are causing several small inefficiencies. If anyone has any thoughts or suggestions - I'd sincerely appreciate your time. Thanks!
1 Like
I have the same problems created ERC-20 with Wizard - https://etherscan.io/address/0x47107774a8d4E17e0560FbDDa3F7318D89C012be
1 Like
| Description | Severity |
|---|---|
| ##### AbiReencodingHeadOverflowWithStaticArrayCleanup |
ABI-encoding a tuple with a statically-sized calldata array in the last component would corrupt 32 leading bytes of its first dynamically encoded component.|When ABI-encoding a statically-sized calldata array, the compiler always pads the data area to a multiple of 32-bytes and ensures that the padding bytes are zeroed. In some cases, this cleanup used to be performed by always writing exactly 32 bytes, regardless of how many needed to be zeroed. This was done with the assumption that the data that would eventually occupy the area past the end of the array had not yet been written, because the encoder processes tuple components in the order they were given. While this assumption is mostly true, there is an important corner case: dynamically encoded tuple components are stored separately from the statically-sized ones in an area called the tail of the encoding and the tail immediately follows the head, which is where the statically-sized components are placed. The aforementioned cleanup, if performed for the last component of the head would cross into the tail and overwrite up to 32 bytes of the first component stored there with zeros. The only array type for which the cleanup could actually result in an overwrite were arrays with uint256 or bytes32 as the base element type and in this case the size of the corrupted area was always exactly 32 bytes. The problem affected tuples at any nesting level. This included also structs, which are encoded as tuples in the ABI. Note also that lists of parameters and return values of functions, events and errors are encoded as tuples.
- Link: https://blog.soliditylang.org/2022/08/08/calldata-tuple-reencoding-head-overflow-bug/
- First Introduced: 0.5.8
- Fixed in Version: 0.8.16
- Published:
- Severity<: medium|
Hi, thanks for the reply. Yes. I linked the article you provided in the original post. The problem is I do not understand what the issue is or how to resolve it. I appreciate your detail, but my programming knowledge is limited to interpreted languages. So, I don't understand or recognize most of the vocabulary you are using or the byte code references.
Is there a way you could explain this simply, as if you're talking to a child? Thanks in advance, I sincerely appreciate your time.
Hi there, Brian. Did you ever found out how to fix this issue? I am having this problem on my authorizable contract and I don't see any info on how to fix it. It's unfortunate that it's a common error and not much data on how to fix it. Thanks for your time.
Hi, thanks for reaching out. I have not found a solution for this yet.