code-423n4 / 2023-09-delegate-findings

2 stars 1 forks source link

Not cleaning scratch space/memory after delegatecalls leads to the caller to work with "dirty" memory #320

Closed c4-submissions closed 11 months ago

c4-submissions commented 11 months ago

Lines of code

https://github.com/delegatexyz/delegate-registry/blob/6d1254de793ccc40134f9bec0b7cb3d9c3632bc1/src/libraries/RegistryHashes.sol#L58

Vulnerability details

Impact

NOTE -> the link above is just the most critical example, the issue affects many functions in the libraries in scope

Calls to deployed libraries are done via delegatecalls, so the storage AND MEMORY context in the library is the one of the caller. Sometimes this does not matter because operations are made in memory regions pointed by the free memory pointer and updated accordingly (see Solady repo, for example). However, in this situation (RegistryHashes::location) it does work with scratch space which is reserved for

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

Tools Used

Recommended Mitigation Steps

Assessed type

call/delegatecall

code423n4 commented 11 months ago

Withdrawn by erebus