MIME-Version: 1.0
From: David Rowley <dgrowleyml@gmail.com>
Date: Thu, 2 Apr 2026 17:09:00 +1300
Message-ID: 
 <CAApHDvq0T=iJ0Sf5TNE9yyWwfOeVjmrBt0wSywDnGD9Y4YJQBA@mail.gmail.com>
Subject: Small and unlikely overflow hazard in bms_next_member()
To: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000ef9bc7064e725cbe"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvq0T%3DiJ0Sf5TNE9yyWwfOeVjmrBt0wSywDnGD9Y4YJQBA%40mail.gmail.com>
Precedence: bulk

--000000000000ef9bc7064e725cbe
Content-Type: text/plain; charset="UTF-8"

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

--000000000000ef9bc7064e725cbe
Content-Type: application/octet-stream; name="bms_next_member_fix.patch"
Content-Disposition: attachment; filename="bms_next_member_fix.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mngy1tt60>
X-Attachment-Id: f_mngy1tt60

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL25vZGVzL2JpdG1hcHNldC5jIGIvc3JjL2JhY2tlbmQv
bm9kZXMvYml0bWFwc2V0LmMKaW5kZXggNzg2ZjM0M2IzYzkuLjkxMmExYWI2OTZhIDEwMDY0NAot
LS0gYS9zcmMvYmFja2VuZC9ub2Rlcy9iaXRtYXBzZXQuYworKysgYi9zcmMvYmFja2VuZC9ub2Rl
cy9iaXRtYXBzZXQuYwpAQCAtMTI4OSw2ICsxMjg5LDcgQEAgYm1zX2pvaW4oQml0bWFwc2V0ICph
LCBCaXRtYXBzZXQgKmIpCiBpbnQKIGJtc19uZXh0X21lbWJlcihjb25zdCBCaXRtYXBzZXQgKmEs
IGludCBwcmV2Yml0KQogeworCWludDY0CQljdXJyYml0OwogCWludAkJCW53b3JkczsKIAliaXRt
YXB3b3JkCW1hc2s7CiAKQEAgLTEyOTcsMTMgKzEyOTgsMTMgQEAgYm1zX25leHRfbWVtYmVyKGNv
bnN0IEJpdG1hcHNldCAqYSwgaW50IHByZXZiaXQpCiAJaWYgKGEgPT0gTlVMTCkKIAkJcmV0dXJu
IC0yOwogCW53b3JkcyA9IGEtPm53b3JkczsKLQlwcmV2Yml0Kys7Ci0JbWFzayA9ICh+KGJpdG1h
cHdvcmQpIDApIDw8IEJJVE5VTShwcmV2Yml0KTsKLQlmb3IgKGludCB3b3JkbnVtID0gV09SRE5V
TShwcmV2Yml0KTsgd29yZG51bSA8IG53b3Jkczsgd29yZG51bSsrKQorCWN1cnJiaXQgPSAoaW50
NjQpIHByZXZiaXQgKyAxOworCW1hc2sgPSAofihiaXRtYXB3b3JkKSAwKSA8PCBCSVROVU0oY3Vy
cmJpdCk7CisJZm9yIChpbnQgd29yZG51bSA9IFdPUkROVU0oY3VycmJpdCk7IHdvcmRudW0gPCBu
d29yZHM7IHdvcmRudW0rKykKIAl7CiAJCWJpdG1hcHdvcmQJdyA9IGEtPndvcmRzW3dvcmRudW1d
OwogCi0JCS8qIGlnbm9yZSBiaXRzIGJlZm9yZSBwcmV2Yml0ICovCisJCS8qIGlnbm9yZSBiaXRz
IGJlZm9yZSBjdXJyYml0ICovCiAJCXcgJj0gbWFzazsKIAogCQlpZiAodyAhPSAwKQo=
--000000000000ef9bc7064e725cbe--