The vulnerability lies in the fact that the ethereum crate did not check for signature malleability for EIP-2930, EIP-1559, and EIP-7702 transactions, which is a deviation from the Ethereum specification (EIP-2). This means that for a single transaction, multiple valid signatures could be created, potentially leading to transaction hash collisions and replay issues in some contexts.
The root cause was that the RLP decoding functions for these transaction types directly assigned the r and s components of the signature without validating them. Specifically, they did not check if the s value was in the lower half of the elliptic curve order.
The patch addresses this by introducing a TransactionSignature::new function that performs the necessary validation. The rlp::Decodable::decode implementations for the affected transaction types (EIP1559Transaction, EIP2930Transaction, EIP7702Transaction, and AuthorizationListItem) were modified to use this new function, thus ensuring that any decoded signature is valid and not malleable.
Additionally, the serde::Deserialize implementations for transaction signatures were also hardened to prevent accepting malleable signatures from other data sources like JSON.