Open c4-submissions opened 1 year ago
Could be similar to #114
bytes032 marked the issue as sufficient quality report
141345 marked the issue as duplicate of #117
Not needed. The total number of batches committed is a critical number. Not duplicate of 117.
miladpiri (sponsor) disputed
GalloDaSballo changed the severity to QA (Quality Assurance)
GalloDaSballo marked the issue as not a duplicate
GalloDaSballo marked the issue as unsatisfactory: Invalid
Lines of code
ttps://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/contracts/ethereum/contracts/zksync/facets/Executor.sol#L212 https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/contracts/ethereum/contracts/zksync/facets/Executor.sol#L206
Vulnerability details
Impact
Revert batch does not clear the state properly in executor facet
Proof of Concept
In the current flow of batch transaction on executor facet
the validator
the executed batches cannot be revert
but if the batch is not executed, even the batch is commited and proved
the validator can revert the batch
but when revert the batch, the state that are updated during commitBatch and proveBatches and not properly cleared
during commit batch, we already update the state s.storedBatchHashes update s.storedBatchHashes in both commit that trigger system upgrade and commit that does not trigger system upgrade
but when reverting the batch, the outdated s.storedBatchHashes is never cleared and removed
then later when commiting other batch, the validator has to supply the wrong and oudated lastBatchCommitData
Tools Used
Manual Review
Recommended Mitigation Steps
clear and reset the state of s.storedBatchHashes
Assessed type
Other