Small and unlikely overflow hazard in bms_next_member()

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

Responses

Browse pgsql-hackers by date

  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