Re: glibc qsort() vulnerability

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Nathan Bossart <nathandbossart@gmail.com>

Cc: Mats Kindahl <mats@timescale.com>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@lists.postgresql.org

Date: 2024-02-09T16:27:28Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Use new overflow-safe integer comparison functions.
- 3b42bdb47169 17.0 landed
Introduce overflow-safe integer comparison functions.
- 6b80394781c8 17.0 landed
Replace calls to pg_qsort() with the qsort() macro.
- 5497daf3aa2a 17.0 landed
Switch over to using our own qsort() all the time, as has been proposed
- 6edd2b4a91bd 8.2.0 cited

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Fri, Feb 09, 2024 at 08:52:26AM +0100, Mats Kindahl wrote:
>> The types "int" and "size_t" are treated as s32 and u32 respectively since
>> that seems to be the case for most of the code, even if strictly not
>> correct (size_t can be an unsigned long int for some architecture).

> Why is it safe to do this?

We do pretty much assume that "int" is "int32".  But I agree that
assuming anything about the width of size_t is bad.  I think we need
a separate pg_cmp_size() or pg_cmp_size_t().

			regards, tom lane