Inheritable Smart Contract Wallet

Summary

The nonReentrant modifier in the InheritanceManager contract contains a critical implementation flaw where it checks for reentrancy at transient storage slot 1 but sets the lock flag at slot 0. This mismatch completely nullifies the reentrancy protection, which could be exploited in specific scenarios where reentrancy protection is needed.

Vulnerability Details

The nonReentrant modifier is implemented with inconsistent transient storage slot usage:

When a protected function is called, the modifier sets a lock at slot 0, but subsequent reentrant calls check slot 1, which remains at its default value of 0. This means the reentrancy check is completely ineffective.

Impact

The severity is high because:

1. It completely nullifies an intended security mechanism

2. It creates a false sense of security for developers who believe their functions are protected against reentrancy

3. It could lead to vulnerabilities in future extensions or upgrades of the contract

4. In the inheritance scenario (which is the core purpose of this contract), if ownership is transferred to a malicious contract during the inheritance process, that contract could exploit the broken reentrancy protection

While the current functions using nonReentrant also have onlyOwner, which mitigates immediate exploitation, the broken reentrancy protection represents a significant security vulnerability that undermines the contract's security model.

Tools Used

Manual code review

Recommendations

Ensure consistent use of the same transient storage slot for both checking and setting the reentrancy lock: