Inheritable Smart Contract Wallet

Summary

During a manual code review, the nonReentrant modifier in the InheritanceManager.sol contract referenced an external Solidity blog post on Transient Storage for Reentrancy Locks. Upon navigating to the URL provided in the NatSpec comment (https://soliditylang.org/blog/2024/01/26/transient-storage/), I compared the implementation in the official blog with the one in the contract and found a critical mismatch in the transient storage slot used for reentrancy protection.

This discrepancy allows a bypass of the reentrancy guard, enabling double execution of critical functions like withdrawals, token transfers, or contract interactions.

Vulnerability Details

Root Cause

The vulnerability arises due to a mismatch between the transient storage slot checked for reentrancy (tload(1)) and the slot used for locking (tstore(0, 1)).

tload(1) checks the wrong slot, while tstore(0, 1) locks another.

Since the tload(1) check is pointing to the wrong transient storage slot, reentrancy is not properly prevented.

Check (tload(1)) looks at transient storage slot 1.

• Lock (tstore(0, 1)) sets transient storage slot 0 to 1.

• Unlock (tstore(0, 0)) resets transient storage slot 0.

Since the check and lock operate on different slots, a reentrant call can bypass the check and re-enter the function.

Reentrancy Not Properly Prevented

• A reentrant call might check tload(0), which is 0, allowing it to execute, even though tload(1) was used in the check.

Impact

This vulnerability completely breaks the reentrancy protection

Tools Used

manual review

Recommendations

Use a Consistent Transient Storage Slot

The transient storage slot must be the same for checking and locking.

Both tload(0) and tstore(0, 1) use the same transient slot (0).

• Ensures proper locking and prevents reentrancy attacks.