[HIGH] StringUtil::toHex(bytes) under-allocates free memory, enabling deterministic memory overlap that corrupts hex strings and downstream dynamic data

[cygent-dev]

Security Finding

Field	Value
Severity	HIGH
Category	storage_collision
Repository	1inch/solidity-utils
Confidence	70%

Description

This storage collision vulnerability arises because StringUtil::toHex(bytes) advances the Solidity free-memory pointer without aligning it to the 32-byte boundaries that the function itself uses for writes, causing deterministic overlap with subsequent allocations. Any caller that supplies revert data or other byte arrays whose length is not divisible by 32 triggers the mismatch between reserved and actually written memory, so later allocations reuse already populated buffers and corrupt returned hex strings as well as downstream dynamic state.

[Truncated - see PR for full details]

Location

• StringUtil.sol:L70-L92 in toHex(bytes) (StringUtil)
• StringUtil.sol:L70-L77 in toHex(bytes) (StringUtil)
• StringUtil.sol:L79-L92 in toHex(bytes) (StringUtil)
• RevertReasonParser.sol:L64-L70 in parse(bytes,string) (RevertReasonParser)
• RevertReasonForwarder.sol:L28-L35 in reReason() (RevertReasonForwarder)

Impact

Hex strings returned by StringUtil::toHex(bytes) become corrupted or truncated when later allocations overwrite the buffer, leading to malformed revert reason strings, incorrect dynamic data observed by callers, and potential DoS or logic corruption when subsequent operations rely on intact memory.

Recommendation

Align the reserved memory to 32-byte boundaries before advancing the free pointer so that every 32-byte mstore remains within the allocated region. Compute the end address as toPtr + resultLength, round it up to the next multiple of 32, and store that rounded value at slot 0x40.

[Truncated - see PR for full details]

---

Created by CARA Security Audit via Cygent