fix(bb): pad gemini_masking_poly size to even to avoid sumcheck OOB#22918
Closed
AztecBot wants to merge 1 commit into
Closed
fix(bb): pad gemini_masking_poly size to even to avoid sumcheck OOB#22918AztecBot wants to merge 1 commit into
AztecBot wants to merge 1 commit into
Conversation
AztecBot
added
ci-draft
iakovenkos
added a commit
that referenced
this pull request
May 6, 2026
…2937) ## Summary Nightly debug build was failing again because `OinkProver::commit_to_masking_poly` allocates `gemini_masking_poly` with size `max_end_index()`. When that value is odd, sumcheck's pairwise iteration over `(edge_idx, edge_idx + 1)` reads one element past the polynomial — `compute_effective_round_size` itself rounds the iteration bound up to even, but the masking polynomial wasn't padded to match. In release builds this is silent UB; in debug, the bounds-checked accessor inside `Polynomial::operator[]` trips and the build fails very early (~2 minutes wall-clock, consistent with the failing job duration). Fix: round the masking polynomial's allocation up to even at construction so the layout matches what sumcheck assumes. The change only ever enlarges the polynomial by at most one element and never affects non-ZK flavors (gated by `flavor_has_gemini_masking<Flavor>()`). ## Recurrence This is the **fifth** independent claudebox session converging on this exact patch over the past four days; the prior four (`claudebox/fix-bb-debug-nightly` 2026-05-01, `claudebox/fix-nightly-bb-debug-build` 2026-05-03, PR #22918 2026-05-04, plus an earlier branch) were not merged, so the bug recurred each night. The diff here is byte-for-byte identical to the closed PR #22918. Most recent visible failed run: https://github.com/AztecProtocol/aztec-packages/actions/runs/25303760883 ## Verification - `cmake --preset debug` configures cleanly. - `ninja ultra_honk_tests` builds cleanly in the `debug` preset. - `./bin/ultra_honk_tests --gtest_filter='*Gemini*:*ZK*:*Mask*'` — **28 passed, 6 skipped** (the 6 skips are flavor-gated, not regressions). Detailed analysis: https://gist.github.com/AztecBot/97de8e254a5df2dad90f895be7d28f08 ClaudeBox log: https://claudebox.work/s/bd19299558fa14bc?run=1 ClaudeBox log: https://claudebox.work/s/bd19299558fa14bc?run=1 --------- Co-authored-by: sergei iakovenko <105737703+iakovenkos@users.noreply.github.com> Co-authored-by: iakovenkos <sergey.s.yakovenko@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Nightly debug build was failing because
OinkProver::commit_to_masking_polyallocatesgemini_masking_polywith sizemax_end_index(). When that value is odd, sumcheck's pairwise iteration over(edge_idx, edge_idx + 1)reads one element past the polynomial —compute_effective_round_sizeitself rounds the iteration bound up to even, but the masking polynomial wasn't padded to match. In release builds this is silent UB; in debug, the bounds-checked accessor insidePolynomial::operator[]trips and the build fails.Fix: round the masking polynomial's allocation up to even at construction so the layout matches what sumcheck assumes. The change only ever enlarges the polynomial by at most one element and never affects non-ZK flavors (gated by
flavor_has_gemini_masking<Flavor>()).Failing run: https://github.com/AztecProtocol/aztec-packages/actions/runs/25303834239
Verification
cmake --preset debug && ninja -C build-debug ultra_honk_testsbuilds cleanly.ultra_honk_tests --gtest_filter='*Gemini*:*ZK*:*Mask*'— 28 passed, 6 skipped (those skips are flavor-gated, not regressions).claudebox/fix-bb-debug-nightly2026-05-01 andclaudebox/fix-nightly-bb-debug-build2026-05-03); neither was merged, so the bug recurred.Detailed analysis: https://gist.github.com/AztecBot/a257fda5daed5f6ef67e07965f30eb11
ClaudeBox log: https://claudebox.work/s/7b79840af9fed45c?run=1