Lack of SAFEAPPROVE(o) in the INITIALIZER which can only be can only be called once

[code423n4]

Lines of code

https://github.com/code-423n4/2022-06-notional-coop/blob/main/notional-wrapped-fcash/contracts/wfCashBase.sol#:~:text=assetToken.safeApprove(address(NotionalV2)%2C%20type(uint256).max)%3B
https://github.com/code-423n4/2022-06-notional-coop/blob/main/notional-wrapped-fcash/contracts/wfCashBase.sol#:~:text=underlyingToken.safeApprove(address(NotionalV2)%2C%20type(uint256).max)%3B

Vulnerability details

Impact

The users won't be able to go back to initialize for that specific fCash asset once the safeApprove reverts because the safeApprove() has a non-zero value.

Proof of Concept

https://github.com/code-423n4/2022-06-notional-coop/blob/main/notional-wrapped-fcash/contracts/wfCashBase.sol#:~:text=assetToken.safeApprove(address(NotionalV2)%2C%20type(uint256).max)%3B
https://github.com/code-423n4/2022-06-notional-coop/blob/main/notional-wrapped-fcash/contracts/wfCashBase.sol#:~:text=underlyingToken.safeApprove(address(NotionalV2)%2C%20type(uint256).max)%3B

When using deprecated function it could leas to unintended reverts and since its the initializer function you get locked out and can't call it again. More understanding about this issue could be link here: OpenZeppelin/openzeppelin-contracts#2219

Tools Used

Manuel Review

Recommended Mitigation Steps

Approve with a zero amount first before setting the actual amount. Consider use safeIncreaseAllowance and safeDecreaseAllowance.

[jeffywu]

It's not clear how there would be a non zero allowance on initialization which can only be called once.