Contract accepts unqueued Tx as input leading to multiple unexpected behavior & Impacts
Description
Brief/Intro
The cancelTransaction() in Timelock .sol does not check that input is a valid queued Tx. This leads to multiple undesired scenarios / impacts. They include:
Impact Details
In a situation of input error, contract will:
Not actually delete Tx as intended.
Contract can wrongly emit / publish wrong data to have been cancelled. Hence deceiving the public.
A reversed Decision (cancelled TX) may still go through undesirously.
POC
See below.
Mitigation
function cancelTransaction(address target, bytes memory callData, uint256 operationId) public { // Community multisig can call this by via executeTransaction if (msg.sender != OPERATIONS_MULTISIG && msg.sender != address(this)) { revert Unauthorized(); } bytes32 txHash = keccak256(abi.encode(target, callData, operationId));+ uint cacheUint = queue[txHash];+ require (cacheUint > 0, "Timelock: unqueued Tx"); queue[txHash] = 0; emit TransactionCanceled(txHash, target, callData, operationId); }