safeTransferFrom fails when casting the 'to' address down from a value greater than max(uint160)

[gasperbr]

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "forge-std/Test.sol";
import "solmate/utils/SafeTransferLib.sol";
import "solmate/tokens/ERC20.sol";

contract ContractTest is Test {

    Token token = new Token();
    Router router = new Router();

    function setUp() public {
        token.approve(address(router), 1);
    }
    function testSafeTransferOk() public {
        router.safeTransferSucceeds(address(token)); // Ok.
    }
    function testSafeTransferNok() public {
        router.safeTransferFails(address(token)); // This fails.
    }
}

contract Router {
    function safeTransferSucceeds(address token) public {
        address to = address(uint160(uint256(0x000000000000000000000000ffffffffffffffffffffffffffffffffffffffff))); // type(uint160).max
        SafeTransferLib.safeTransferFrom(ERC20(token), msg.sender, to, 1);
    }
    function safeTransferFails(address token) public {
        address to = address(uint160(uint256(0x0000000000000000000000010000000000000000000000000000000000000000))); // type(uint160).max + 1
        SafeTransferLib.safeTransferFrom(ERC20(token), msg.sender, to, 1);
    }
}

contract Token is ERC20("", "", 18) {
    constructor() {
        _mint(msg.sender, 1);
    }
}

[regohiro]

Encountered the same issue. This is also true for "from". A temporary fix is to mask the address:

address(uint160(uint256(0x0000000000000000000000010000000000000000000000000000000000000000)) & type(uint160).max)

[NikitaZ]

We encountered the same with most recent UniversalRouter from Uniswap, the one which supports v4 (even though it is from 2024, it uses rather old version of Solady). The issue happens when it is deployed locally, and built without via-ir. On the Mainnet it doesn't happen. It affects only V2Swaps in case payer_is_user = false - then safeTransfer() is used to transfer funds to a V2 pool before calling UniswapV2::swap() and 'to' argument is equal to some keccak256:

V2 Pair address is calculated like this

address firstPair =
        UniswapV2Library.pairFor(UNISWAP_V2_FACTORY, UNISWAP_V2_PAIR_INIT_CODE_HASH, path[0], path[1]);
...where...
pair = address(
    uint160(
        uint256(
            keccak256(
                abi.encodePacked(hex"ff", factory, keccak256(abi.encodePacked(token0, token1)), initCodeHash)
            )
        )
    )
);

This firstPair still has garbage in the top bits, so due to this issue we get a transfer with address which is not masked properly:

    ├─ [336] USDC@0xa4CCee59f422260600bbeBe1995C91a141A65b09::transfer(f4fe3d556059c4905cdc712d46d132881a09d23d647a19de1778a5a9750c4500000000000000000000000000000000000000000000000000000000001903aad5)
    │   └─ ← [Revert]
    └─ ← [Revert] 0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000f5452414e534645525f4641494c45440000000000000000000000000000000000
Error("TRANSFER_FAILED")

It doesn't affect V3 swaps as transfer happens from unlock callback and there address(this) is used.

[NikitaZ]

@saucepoint What do you think?

[NikitaZ]

(looks like the bug is there when UniswapRouter is compiled without via-ir, or maybe the bug is still there but at least we couldn't trigger it so far)