[ghoshp83]

Closes #3979

Rationale for this change

_deserialize_bitmap read an 8-byte count from the start of the payload and used it directly as a loop bound, without relating it to how much payload actually follows. A small blob could therefore declare a very large number of bitmaps.

The count cannot be trusted on its own, but it can be checked against the payload: every bitmap contributes at least a 4-byte key, so a count larger than len(payload) // 4 cannot be satisfied by the bytes present. This rejects such a payload up front with a ValueError instead of letting the loop run off the end of the buffer, which surfaced as IndexError: Out of bounds on buffer access (axis 0) from the native bitmap decoder.

Per SECURITY-THREAT-MODEL.md this is parser hardening (§7) rather than a vulnerability, so it is filed as an ordinary bug fix.

Are these changes tested?

Yes. tests/table/test_deletion_vector.py gains a case for a payload that declares more bitmaps than its bytes can hold. It fails on main with the IndexError above and passes with this change; the existing deletion-vector tests are unaffected.

Are there any user-facing changes?

A deletion vector whose declared bitmap count exceeds its payload now raises ValueError instead of IndexError. Valid deletion vectors are unaffected.

One related case is deliberately left out of this PR to keep it to a single concern: a single large key still drives the empty-bitmap fill loop up to MAX_JAVA_SIGNED appends, which is the same shape of problem reached through a different field. Happy to follow up on that separately if you would like it addressed.

[ghoshp83]

Checking in on this one, and offering to close out the question in the description.

The PR rejects a bitmap count larger than the payload. It deliberately leaves one adjacent case alone: a single large key still drives the empty-bitmap fill loop up to MAX_JAVA_SIGNED, which is slow rather than wrong, and fixing it changes different code than this bounds check.

Happy to go either way — fold that into this PR, or send it separately once this lands. If you would rather it were one change, say so and I will extend this one instead of leaving the question open.

[ghoshp83]

Still current: CI is green and the branch merges cleanly against main. The open question from the description (whether the large-key fill loop should be bounded here or in a follow-up) still stands, and I am happy to go either way.