| From: | Mats Kindahl <mats(at)timescale(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: glibc qsort() vulnerability |
| Date: | 2024-02-08 11:01:22 |
| Message-ID: | CA+14427HmRRcPVzWHYTTnq+=ATbx0znqv_87GdC+C9TFqPKB6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 7, 2024 at 9:56 PM Nathan Bossart <nathandbossart(at)gmail(dot)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?
> > 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
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2024-02-08 11:01:55 | Re: Psql meta-command conninfo+ |
| Previous Message | shveta malik | 2024-02-08 11:01:18 | Re: Synchronizing slots from primary to standby |