Re: glibc qsort() vulnerability

On 07/02/2024 11:09, Mats Kindahl wrote:
> On Tue, Feb 6, 2024 at 9:56 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Nathan Bossart <nathandbossart(at)gmail(dot)com
> <mailto:nathandbossart(at)gmail(dot)com>> writes:
> > Even if the glibc issue doesn't apply to Postgres, I'm tempted to
> suggest
> > that we make it project policy that comparison functions must be
> > transitive.  There might be no real issues today, but if we write all
> > comparison functions the way Mats is suggesting, it should be
> easier to
> > reason about overflow risks.
>
> A comparison routine that is not is probably broken, agreed.
> I didn't look through the details of the patch --- I was more
> curious whether we had a version of the qsort bug, because
> if we do, we should fix that too.
>
> The patch basically removes the risk of overflow in three routines and
> just returns -1, 0, or 1, and adds a comment in one.
>
> The routines modified do a subtraction of int:s and return that, which
> can cause an overflow. This method is used for some int16 as well but
> since standard conversions in C will perform the arithmetics in "int"
> precision, this cannot overflow, so added a comment there. It might
> still be a good idea to follow the same pattern for the int16 routines,
> but since there is no bug there, I did not add them to the patch.

Doesn't hurt to fix the comparison functions, and +1 on using the same
pattern everywhere.

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.

--
Heikki Linnakangas
Neon (https://neon.tech)