If the fulfiller is USDC blacklisted and the ERC20 payment is in USDC, the offerer cannot get their NFT back

[c4-bot-4]

Lines of code

https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/policies/Stop.sol#L296

Vulnerability details

Impact

If the fulfiller is USDC blacklisted and the ERC20 payment is in USDC, the offerer cannot get their NFT back

Proof of Concept

In Stop.sol, stopRent() will handle transfer both ERC20 payment and assets(ERC721/ERC1155) when a rental order expires.

The vulnerability is that when the fulfiller is USDC blacklisted and if the ERC20 token in question is USDC, the offerer will not abe able to get their asset token back, due to the fact that ECRW.settlePayment(order) which handles ERC20 payment will revert during token transfer, and reverting the entire stopRent() transaction.

//src/policies/Stop.sol
    function stopRent(RentalOrder calldata order) external {
...
|>       ESCRW.settlePayment(order);
...

(https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/policies/Stop.sol#L296)

Tools Used

Manual Review

Recommended Mitigation Steps

Consider adding try-catch black inside the ESCRW.settlePayment() token transfer flow when the erc20 is USDC or other ERC20 with blacklisting features.

Assessed type

Other

[c4-pre-sort]

141345 marked the issue as duplicate of #64

[c4-judge]

0xean marked the issue as satisfactory