| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Small and unlikely overflow hazard in bms_next_member() |
| Date: | 2026-04-02 04:09:00 |
| Message-ID: | CAApHDvq0T=iJ0Sf5TNE9yyWwfOeVjmrBt0wSywDnGD9Y4YJQBA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| bms_next_member_fix.patch | application/octet-stream | 905 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-04-02 04:15:48 | Re: Check some unchecked fclose() results |
| Previous Message | Alexander Lakhin | 2026-04-02 04:00:00 | Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE |