Small and unlikely overflow hazard in bms_next_member()
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-02T04:09:00Z
Lists: pgsql-hackers
Attachments
- bms_next_member_fix.patch (application/octet-stream) patch
I've been working on bms_left_shift_members() to bitshift members either left or right in order to tidy up some existing code and improve a future Bitmapset use case I'm currently working on. When testing some ERROR code I added to ensure we don't get an excessively large left shift value and end up with members higher than INT32_MAX, I discovered that bms_next_member() can't handle that value, as "prevbit++" will wrap to INT32_MIN and then we'll try to access a negative array index, i.e. seg fault. I appreciate that such a large member is quite unlikely, but if this isn't fixed then I need to code my error checking code to disallow members >= INT32_MAX rather than > INT32_MAX. I did have a comment explaining why I was doing that, but fixing the bug saves the weird special case and the comment. Patched attached. I was thinking it might not be worthy of backpatching, but I'll entertain alternative views on that. David
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix unlikely overflow bug in bms_next_member()
- e3e26d04bd52 19 (unreleased) landed