| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Mats Kindahl <mats(at)timescale(dot)com>, 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-07 20:56:00 |
| Message-ID: | 20240207205600.GA378707@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
> 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
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-remove-direct-calls-to-pg_qsort.patch | text/x-diff | 3.6 KB |
| v2-0002-Ensure-comparison-functions-are-transitive.patch | text/x-diff | 3.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2024-02-07 21:46:52 | Re: Statistics Import and Export |
| Previous Message | Euler Taveira | 2024-02-07 20:54:29 | Re: speed up a logical replica setup |