Skip to content

[storage/fuzz] fix mmr_journaled fuzz test #2746

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
roberto-bayardo merged 1 commit into from
Jan 8, 2026
Merged

[storage/fuzz] fix mmr_journaled fuzz test #2746

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions storage/fuzz/fuzz_targets/mmr_journaled.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -437,9 +437,10 @@ fn fuzz(input: FuzzInput) {
)
.await
.unwrap();
// Reset tracking variables to match recovered state
leaves.clear();
historical_sizes.clear();
// Truncate tracking variables to match recovered state
let recovered_leaves = new_mmr.leaves().as_u64() as usize;
leaves.truncate(recovered_leaves);
historical_sizes.truncate(recovered_leaves);
Copy link

@cursor cursor bot Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong tracking data after pop-add-reinit sequence

Low Severity

The truncation logic assumes leaves[0..recovered_leaves] matches the recovered MMR's leaves. This breaks after a Pop-Add sequence without sync. For example: sync with [A,B], pop one leaf giving [A], add C giving [A,C], then Reinit recovers 2 leaves. leaves.truncate(2) keeps [A,C] but the recovered MMR has [A,B]. Subsequent Proof operations use wrong element data (C instead of B), causing spurious verification failures that misleadingly suggest bugs in the MMR implementation.

🔬 Verification Test

Why verification test was not possible: This is a fuzz test infrastructure issue in a Rust project that requires the full commonware-storage crate and its dependencies to compile and run. The bug manifests as spurious assertion failures during fuzz testing when a specific operation sequence (sync → pop → add → reinit) occurs, which cannot be easily unit tested in isolation without the full fuzzing framework.

Fix in Cursor Fix in Web

Copy link
Collaborator Author

@roberto-bayardo roberto-bayardo Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pop does a sync, so this should be fine.

MmrState::Clean(new_mmr)
}

Expand Down
Loading