Small and unlikely overflow hazard in bms_next_member() - Mailing list pgsql-hackers

From David Rowley
Subject Small and unlikely overflow hazard in bms_next_member()
Date
Msg-id CAApHDvq0T=iJ0Sf5TNE9yyWwfOeVjmrBt0wSywDnGD9Y4YJQBA@mail.gmail.com
Whole thread
Responses Re: Small and unlikely overflow hazard in bms_next_member()
Re: Small and unlikely overflow hazard in bms_next_member()
List 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

pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Next
From: Chao Li
Date:
Subject: Re: Check some unchecked fclose() results