In _extractPreimagePart, it is possible that non-zero bytes can be stored in the proposalParts and then the preimageParts because calldataload is used to load the next 32 bytes from the offset which will may overshoot the end of the _input calldata. Someone can craft calldata such that there can be non-zero bytes in the padding between the _input calldata and the _stateCommitments to store it in the preimagePart.
This is not exploitable because the MIPS VM will use the preimageLengths to only read bytes up to the tail end of the preimage but it might be good defense-in-depth to fix this.
