Date: Sat, 10 Feb 2024 14:53:32 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: Mats Kindahl <mats@timescale.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
	Thomas Munro <thomas.munro@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: glibc qsort() vulnerability
Message-ID: <20240210205332.GA1124797@nathanxps13>
References: <1074897.1707417842@sss.pgh.pa.us>
 <20240208195954.vlpoii4ftoow2of4@awork3.anarazel.de>
 <20240208200737.GA504276@nathanxps13>
 <1242426.1707424769@sss.pgh.pa.us>
 <CA+14425sEcy-KzCE1ztpO=XrHZ5u_5tR2UNsw6874dVbAShpzQ@mail.gmail.com>
 <20240209162433.GA663211@nathanxps13>
 <CA+14427pVjvgnVGiyM45e_EyKgCmzgRiK3dSQJqfOtHAnY8Maw@mail.gmail.com>
 <CA+14427QfHELBNskJKPHA96yOJ6aUZE_XqbFBC7hz+hmywTtPQ@mail.gmail.com>
 <20240209200828.GB665650@nathanxps13>
 <CA+14425kn0RxC62M7ZaD5BRzBJEPRRLQQB4DGdL+=vxHS1E81Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+14425kn0RxC62M7ZaD5BRzBJEPRRLQQB4DGdL+=vxHS1E81Q@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20240210205332.GA1124797%40nathanxps13>
Precedence: bulk

On Sat, Feb 10, 2024 at 08:59:06AM +0100, Mats Kindahl wrote:
> Split the code into two patches: one that just adds the functions
> (including the new pg_cmp_size()) to common/int.h and one that starts using
> them. I picked the name "pg_cmp_size" rather than "pg_cmp_size_t" since
> "_t" is usually used as a suffix for types.
> 
> I added a comment to the (a > b) - (a < b) return and have also added casts
> to (int32) for the int16 and uint16 functions (we need a signed int for
> uin16 since we need to be able to get a negative number).
> 
> Changed the type of two instances that had an implicit cast from size_t to
> int and used the new pg_,cmp_size() function.
> 
> Also fixed the missed replacements in the "contrib" directory.

Thanks for the new patches.  I think the comparison in resowner.c is
backwards, and I think we should expand on some of the commentary in int.h.
For example, the comment at the top of int.h seems very tailored to the
existing functions and should probably be adjusted.  And the "comparison
routines for integers" comment might benefit from some additional details
about the purpose and guarantees of the new functions.

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