Re: glibc qsort() vulnerability - Mailing list pgsql-hackers

From Mats Kindahl
Subject Re: glibc qsort() vulnerability
Date
Msg-id CA+14427q5qECvDg+m49RKcdEzRvbQ39U_9ta10LUW=6ZMLpe+g@mail.gmail.com
Whole thread Raw
In response to Re: glibc qsort() vulnerability  (Mats Kindahl <mats@timescale.com>)
List pgsql-hackers
On Thu, Feb 8, 2024 at 12:01 PM Mats Kindahl <mats@timescale.com> wrote:
On Wed, Feb 7, 2024 at 9:56 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Wed, Feb 07, 2024 at 08:46:56PM +0200, Heikki Linnakangas wrote:
> Doesn't hurt to fix the comparison functions, and +1 on using the same
> pattern everywhere.

I attached a new version of the patch with some small adjustments.  I
haven't looked through all in-tree qsort() comparators to see if any others
need to be adjusted, but we should definitely do so as part of this thread.
Mats, are you able to do this?

Sure, I checked them and the only ones remaining are those using int16. Shall I modify those as well?

Seems your additional patch dealt with at least one of the cases.
 
 
> However, we use our qsort() with user-defined comparison functions, and we
> cannot make any guarantees about what they might do. So we must ensure that
> our qsort() doesn't overflow, no matter what the comparison function does.
>
> Looking at our ST_SORT(), it seems safe to me.

Cool.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Thoughts about NUM_BUFFER_PARTITIONS
Next
From: jian he
Date:
Subject: Re: Catalog domain not-null constraints