Reentrancy protection can likely be bypassed
The KeyManager offers reentrancy protection for interactions with the associated account. Through the LSP20 callbacks or through the `execute()` calls, it will call `_nonReentrantBefore()` before execution, and `_nonReentrantAfter()` post-execution. The latter will always reset the flag signaling entry.\\n```\\n    function _nonReentrantAfter() internal virtual {\\n    // By storing the original value once again, a refund is triggered \\n             (see // https://eips.ethereum.org/EIPS/eip-2200)\\n        _reentrancyStatus = false;\\n     }\\n```\\n\\nAn attacker can abuse it to reenter provided that there exists some third-party contract with REENTRANCY_PERMISSION that performs some interaction with the contract. The attacker would trigger the third-party code path, which will clear the reentrancy status, and enable attacker to reenter. This could potentially be chained several times. Breaking the reentrancy assumption would make code that assumes such flows to be impossible to now be vulnerable.
In `_nonReentrantAfter()`, the flag should be returned to the original value before reentry, rather than always setting it to false.
```\\n    function _nonReentrantAfter() internal virtual {\\n    // By storing the original value once again, a refund is triggered \\n             (see // https://eips.ethereum.org/EIPS/eip-2200)\\n        _reentrancyStatus = false;\\n     }\\n```\\n