MIME-Version: 1.0
References: <CA+14426g2Wa9QuUpmakwPxXFWG_1FaY0AsApkvcTBy-YfS6uaw@mail.gmail.com>
 <508821.1707232276@sss.pgh.pa.us> <20240206205305.GB3891538@nathanxps13>
 <642084.1707252958@sss.pgh.pa.us> <CA+14425TqyUZ3-O7zYsW6u85yY5diCz-p_TPQ2bZovn-N-fQ9A@mail.gmail.com>
 <cc9b0272-849a-4a88-8200-59786d18b7a1@iki.fi> <20240207205600.GA378707@nathanxps13>
In-Reply-To: <20240207205600.GA378707@nathanxps13>
From: Mats Kindahl <mats@timescale.com>
Date: Thu, 8 Feb 2024 12:01:22 +0100
Message-ID: <CA+14427HmRRcPVzWHYTTnq+=ATbx0znqv_87GdC+C9TFqPKB6g@mail.gmail.com>
Subject: Re: glibc qsort() vulnerability
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, 
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000fb89020610dcbb53"
Archived-At: <https://www.postgresql.org/message-id/CA%2B14427HmRRcPVzWHYTTnq%2B%3DATbx0znqv_87GdC%2BC9TFqPKB6g%40mail.gmail.com>
Precedence: bulk

--000000000000fb89020610dcbb53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 7, 2024 at 9:56=E2=80=AFPM Nathan Bossart <nathandbossart@gmail=
.com>
wrote:

> On Wed, Feb 07, 2024 at 08:46:56PM +0200, Heikki Linnakangas wrote:
> > Doesn't hurt to fix the comparison functions, and +1 on using the same
> > pattern everywhere.
>
> I attached a new version of the patch with some small adjustments.  I
> haven't looked through all in-tree qsort() comparators to see if any othe=
rs
> need to be adjusted, but we should definitely do so as part of this threa=
d.
> Mats, are you able to do this?
>

Sure, I checked them and the only ones remaining are those using int16.
Shall I modify those as well?


> > 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.
>
> Cool.
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
>

--000000000000fb89020610dcbb53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Feb 7, 2024 at 9:56=E2=80=AFPM Na=
than Bossart &lt;<a href=3D"mailto:nathandbossart@gmail.com">nathandbossart=
@gmail.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">On Wed, Feb 07, 2024 at 08:46:56PM +02=
00, Heikki Linnakangas wrote:<br>
&gt; Doesn&#39;t hurt to fix the comparison functions, and +1 on using the =
same<br>
&gt; pattern everywhere.<br>
<br>
I attached a new version of the patch with some small adjustments.=C2=A0 I<=
br>
haven&#39;t looked through all in-tree qsort() comparators to see if any ot=
hers<br>
need to be adjusted, but we should definitely do so as part of this thread.=
<br>
Mats, are you able to do this?<br></blockquote><div><br></div><div>Sure, I =
checked them and the only ones remaining are those using int16. Shall I mod=
ify those as well?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
&gt; However, we use our qsort() with user-defined comparison functions, an=
d we<br>
&gt; cannot make any guarantees about what they might do. So we must ensure=
 that<br>
&gt; our qsort() doesn&#39;t overflow, no matter what the comparison functi=
on does.<br>
&gt; <br>
&gt; Looking at our ST_SORT(), it seems safe to me.<br>
<br>
Cool.<br>
<br>
-- <br>
Nathan Bossart<br>
Amazon Web Services: <a href=3D"https://aws.amazon.com" rel=3D"noreferrer" =
target=3D"_blank">https://aws.amazon.com</a><br>
</blockquote></div></div>

--000000000000fb89020610dcbb53--