Re: [PATCH] bms_prev_member() can read beyond the end of the array of allocated words

From: Greg Burd <greg(at)burd(dot)me>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] bms_prev_member() can read beyond the end of the array of allocated words
Date: 2025-08-14 15:37:28
Message-ID: 62DDA081-A457-4F2A-9D32-0EC988278BFC@getmailspring.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Aug 14 2025, at 11:14 am, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
>> It is valid to pass prevbit as a->nwords * BITS_PER_BITMAPWORD as the
>> code does "prevbit--;". Maybe it would be less confusing if it were
>> written as:
>> * "prevbit" must be less than or equal to "a->nwords * BITS_PER_BITMAPWORD".
>> The Assert should be using <= rather than <.
>
> Actually, I don't agree with that. It's true that it wouldn't fail,
> but a caller doing that is exhibiting undue intimacy with the innards
> of Bitmapsets. The expected usage is that the argument is initially
> -1 and after that the result of the previous call (which'll
> necessarily be less than a->nwords * BITS_PER_BITMAPWORD). We don't
> have any state with which we can verify the chain of calls, but it
> seems totally reasonable to me to disallow an outside caller
> providing an argument >= a->nwords * BITS_PER_BITMAPWORD.
>
> regards, tom lane

Thanks Tom, David,

Seems I also forgot about the case where the Bitmapset passed is NULL.
The new assert needs to handle that as well.

-greg

Attachment Content-Type Size
v3-0001-Prevent-bms_prev_member-from-reading-beyond-the-e.patch application/octet-stream 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Benoît Dufour 2025-08-14 15:40:20 [Feature request] Add a way to get the length of a PQerrorMessage in libpq
Previous Message Nathan Bossart 2025-08-14 15:22:02 pg_upgrade: transfer pg_largeobject_metadata's files when possible