Skip to content

Latest commit

 

History

History
59 lines (38 loc) · 1.66 KB

093.md

File metadata and controls

59 lines (38 loc) · 1.66 KB

Boxy Ash Ant

High

Unsafe Token Approval Pattern Leading to Failed Transactions

Summary

Contracts uses SafeERC20.safeApprove() which has a known limitation where it reverts when changing a non-zero approval to another non-zero value. This can cause order executions to fail when partial fills occur.

Root Cause

This issue here is that OpenZeppelin's safeApprove() function does not allow changing a non-zero allowance to another non-zero allowance. This will therefore cause all subsequent approval of the tokens to fail after the first approval when all approved amount is not used, dossing the contract's order executions.

    function execute(
        address target,
        bytes memory txData,
        uint256 amountIn,
        IERC20 tokenIn,
        IERC20 tokenOut,
        uint16 bips
    ) internal returns (uint256 swapAmountOut, uint256 tokenInRefund) {
        //update accounting
        uint256 initialTokenIn = tokenIn.balanceOf(address(this));
        uint256 initialTokenOut = tokenOut.balanceOf(address(this));

        //approve
        tokenIn.safeApprove(target, amountIn);

https://github.com/sherlock-audit/2024-11-oku/blob/ee3f781a73d65e33fb452c9a44eb1337c5cfdbd6/oku-custom-order-types/contracts/automatedTrigger/Bracket.sol#L539

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

  1. Initial order execution approves X tokens
  2. Only Y tokens are used (Y < X)
  3. Next execution tries to approve
  4. safeApprove() reverts because previous approval wasn't zero

Impact

Failed order executions and creations

PoC

No response

Mitigation

Replace safeApprove with forceApprove