At the time of the audit the wagmi-leverage project used a library called ExternalCall , which provides a function patchAmountAndCall , that is responsible for calling a given target address with a given calldata , that is being patched before.

function _patchAmountAndCall(
        address target,
        bytes calldata data,
        uint256 maxGas,
        uint256 swapAmountInDataIndex,
        uint256 swapAmountInDataValue
    ) internal returns (bool success)

assembly ("memory-safe") {
	let ptr := mload(0x40)
	calldatacopy(ptr, data.offset, data.length)
	if gt(swapAmountInDataValue, 0) {
		mstore(add(add(ptr, 0x24), mul(swapAmountInDataIndex, 0x20)), swapAmountInDataValue)
    }
	success := call(
		maxGas,
		target,
		0, //value
		ptr, //Inputs are stored at location ptr
		data.length,
		0,
		0
	)
// ...
}

So, what is the patching about here:

As this function is intended to call a swap on the given target, and the amountIn is not a user input, but calculated by the contract, it is an argument in the calldata that has to be patched.

Therefore, the user can specify the swapAmountInDataIndex to signal at which index the data has to be patched.

So, if the given swapAmountInDataValue is not 0, we store it a calculated position in memory.

How is this location calculated?

Remember, our current ptr still points to the beginning of our calldata. Now we calculate the location like this:

ptr + 36 (0x24) + swapAmountInDataIndex * 32 (0x20).

We can see that an offset of 32 + 4 bytes is set to respect the function selector. The user can set another offset of n * 32 bytes via the swapAmountInDataIndex to ensure the amount gets stored in the correct position.

This means a calculation with a user-specified value is prone to over/underflow attacks. In this specific case, this could happen at the memory address calculation for the value to patch. add(add(ptr, 0x24), mul(swapAmountInDataIndex, 0x20)).

As the swapAmountInDataIndex is user-specified, and the result is an uint256 , it could be set to a really high value and make the calculation overflow.

By doing this, a malicious actor can overwrite the function selector with a value that was not whitelisted, which finally allows an attacker to call any function with any input on a whitelisted target contract.

In this case, it could be overwritten with the swapAmountInDataValue, which is not a direct user input.

However, as it is the amount of a token that the user could specify, a malicious actor could create and use his own token, granting him fine-grained control over this parameter.

To mitigate this vulnerability in the specific case Sherlock suggested to limit the swapAmountInDataValue parameter to the quotient of the data length and 32 (div(data.length, 0x20)), to allow the value to be put at any valid location inside the calldata, or right at the end of it.