Re: glibc qsort() vulnerability

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>

To: Mats Kindahl <mats@timescale.com>

Cc: Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>, Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org

Date: 2024-02-08T18:38:35Z

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

On Thu, Feb 08, 2024 at 02:16:11PM +0100, Mats Kindahl wrote:
> +/*
> + * Compare two integers and return -1, 0, or 1 without risking overflow.
> + *
> + * This macro is used to avoid running into overflow issues because a simple
> + * subtraction of the two values when implementing a cmp function for qsort().
> +*/
> +#define INT_CMP(lhs,rhs) (((lhs) > (rhs)) - ((lhs) < (rhs)))

I think we should offer a few different macros, i.e., separate macros for
int8, uint8, int16, uint16, int32, etc.  For int16, we can do something
faster like

	(int32) (lhs) - (int32) (rhs)

but for int32, we need to do someting more like what's in the patch.

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