Conversation
There was a problem hiding this comment.
🔴 Submitting the highest bucket number crashes histogram aggregation
A bucket number equal to the number of buckets is accepted instead of rejected (measurement > uint64(h.length) at vdaf/prio3/histogram/histogram.go:126) before the value is used to fill in the bucket list, so a caller can crash the program with an out-of-range access.
Impact: Any client or server call using the last-plus-one bucket value panics instead of getting a clean error, aborting the process.
Off-by-one bound in histogram measurement encoding
Encode allocates a vector of exactly h.Valid.MeasurementLen == length elements (vdaf/prio3/histogram/histogram.go:130) and then writes out[measurement]. Since the guard only rejects measurement > length, passing measurement == length (e.g. New(2, 4, 3, ctx) then Shard(4, ...)) indexes past the end and panics with "index out of range". Per the Prio3Histogram spec the measurement must satisfy 0 <= measurement < length, so the comparison should be >=. This is in the same input-validation area the PR hardens, and REVIEW.md requires no panic on attacker-controlled input plus max-value edge-case coverage.
(Refers to lines 126-128)
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
🟨 Histogram bucket index at the upper bound triggers a panic instead of an error
vdaf/prio3/histogram/histogram.go:126 accepts measurement == length and then writes out[measurement] into a vector of exactly length elements (vdaf/prio3/histogram/histogram.go:130-131), causing an out-of-range panic on caller-supplied input. REVIEW.md/AGENTS.md require inputs to be validated at API boundaries and forbid panics on attacker-controlled input.
(Refers to lines 126-128)
Was this helpful? React with 👍 or 👎 to provide feedback.
Uh oh!
There was an error while loading. Please reload this page.