TransactionDecoder Does Not Account for the Missing Elements While Decoding a Transaction
The library tries to decode calldata from different transaction types, by jumping to the position of calldata element in the rlp encoding. These positions are:\\nEIP1559: 8\\nEIP2930: 7\\nLegacy: 6\\n```\\ndata = it.\\_skipTo(8).\\_toBytes();\\n```\\n\\n```\\ndata = it.\\_skipTo(7).\\_toBytes();\\n```\\n\\n```\\ndata = it.\\_skipTo(6).\\_toBytes();\\n```\\n\\nHowever, the decoder doesn't check whether the required element is there or not in the encoding provided.\\nThe decoder uses the library RLPReader to skip to the desired element in encoding. However, it doesn't revert in case there are not enough elements to skip to, and will simply return byte `0x00`, while still completing unnecessary iterations.\\n```\\nfunction \\_skipTo(Iterator memory \\_self, uint256 \\_skipToNum) internal pure returns (RLPItem memory item) {\\n uint256 ptr = \\_self.nextPtr;\\n uint256 itemLength = \\_itemLength(ptr);\\n \\_self.nextPtr = ptr + itemLength;\\n\\n for (uint256 i; i < \\_skipToNum - 1; ) {\\n ptr = \\_self.nextPtr;\\n itemLength = \\_itemLength(ptr);\\n \\_self.nextPtr = ptr + itemLength;\\n\\n unchecked {\\n i++;\\n }\\n }\\n\\n item.len = itemLength;\\n item.memPtr = ptr;\\n}\\n```\\n\\nAlthough it doesn't impose any security issue, as `ZkEvmV2` tries to decode an array of bytes32 hashes from the rlp encoded transaction. However, it may still lead to errors in other use cases if not handled correctly.\\n```\\nCodecV2.\\_extractXDomainAddHashes(TransactionDecoder.decodeTransaction(\\_transactions[\\_batchReceptionIndices[i]]))\\n```\\n
rlp library should revert if there are not enough elements to skip to in the encoding.
```\\ndata = it.\\_skipTo(8).\\_toBytes();\\n```\\n