Re: glibc qsort() vulnerability - Mailing list pgsql-hackers

From Andres Freund
Subject Re: glibc qsort() vulnerability
Date
Msg-id 20240212213130.jp5vwotwazypaaez@awork3.anarazel.de
Whole thread Raw
In response to Re: glibc qsort() vulnerability  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: glibc qsort() vulnerability
List pgsql-hackers
Hi,

On 2024-02-12 14:51:38 -0600, Nathan Bossart wrote:
> On Mon, Feb 12, 2024 at 06:09:06PM +0100, Mats Kindahl wrote:
> > Here are the two fixed patches.
> 
> These patches look pretty good to me.  Barring additional feedback, I'll
> plan on committing them in the next few days.

One thing that's worth checking is if this ends up with *worse* code when the
comparators are inlined. I think none of the changed comparators will end up
getting used with an inlined sort, but ...

The reason we could end up with worse code is that when inlining the
comparisons would make less sense for the compiler. Consider e.g.
    return DO_COMPARE(a, b) < 0 ?
        (DO_COMPARE(b, c) < 0 ? b : (DO_COMPARE(a, c) < 0 ? c : a))
        : (DO_COMPARE(b, c) > 0 ? b : (DO_COMPARE(a, c) < 0 ? a : c));

With a naive implementation the compiler will understand it only cares about
a < b, not about the other possibilities. I'm not sure that's still true with
the more complicated optimized version.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Pavel Luzanov
Date:
Subject: Re: Things I don't like about \du's "Attributes" column
Next
From: Bharath Rupireddy
Date:
Subject: Re: Fix a typo in pg_rotate_logfile