unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Vincent Lefevre <vincent@vinc17.net>,
	Xi Ruoyao <xry111@xry111.site>,
	Turritopsis Dohrnii Teo En Ming <teo.en.ming@protonmail.com>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	"ceo@teo-en-ming-corp.com" <ceo@teo-en-ming-corp.com>
Subject: Re: New GNU C Library (glibc) security flaw reported on 30 Jan 2024
Date: Wed, 31 Jan 2024 12:52:35 -0300	[thread overview]
Message-ID: <c622583d-a7f5-45ad-8195-0d8238469823@linaro.org> (raw)
In-Reply-To: <20240131145555.GB2102@cventin.lip.ens-lyon.fr>



On 31/01/24 11:55, Vincent Lefevre wrote:
> On 2024-01-31 22:23:32 +0800, Xi Ruoyao wrote:
>> On Wed, 2024-01-31 at 14:08 +0000, Turritopsis Dohrnii Teo En Ming
>> wrote:
>>> Subject: New GNU C Library (glibc) security flaw reported on 30 Jan 2024
>>>
>>> Good day from Singapore,
>>>
>>> I recently stumbled upon this insightful article and wanted to share it with you.
>>>
>>> Article: New Linux glibc flaw lets attackers get root on major distros
>>> Link: https://www.bleepingcomputer.com/news/security/new-linux-glibc-flaw-lets-attackers-get-root-on-major-distros/
>>
>> I cannot see why https://www.qualys.com/2024/01/30/qsort.txt is a
>> **Glibc** security issue.  The standard is clear that if you pass a non-
>> transitive comparator to qsort, you invoke an undefined behavior.
> 
> This is what the ISO C standard says. But the glibc manual explicitly
> allows non-transitive comparators.
> 
> See the example in 9.1 Defining the Comparison Function:
> 
>    Here is an example of a comparison function which works with an array
> of numbers of type ‘double’:
> 
>      int
>      compare_doubles (const void *a, const void *b)
>      {
>        const double *da = (const double *) a;
>        const double *db = (const double *) b;
> 
>        return (*da > *db) - (*da < *db);
>      }
> 
> The non-transitivity can be demonstrated with the following test
> program:
> 
> #include <stdio.h>
> #include <math.h>
> 
> int
> compare_doubles (const void *a, const void *b)
> {
>   const double *da = (const double *) a;
>   const double *db = (const double *) b;
> 
>   return (*da > *db) - (*da < *db);
> }
> 
> int main (void)
> {
>   double t[3] = { 1.0, NAN, 2.0 };
>   printf ("%d\n", compare_doubles(t+0, t+1));
>   printf ("%d\n", compare_doubles(t+1, t+2));
>   printf ("%d\n", compare_doubles(t+0, t+2));
>   return 0;
> }
> 
> which gives
> 
> 0
> 0
> -1
> 
> while the initial 0 0 implies a third 0 with a transitive comparator.
> 

I see this is an manual issue rather than a GNU 'extension' to qsort semantic.
And I think we should fix BZ#31322 by using a transitive comparison instead of
trying to support such cases.

  reply	other threads:[~2024-01-31 15:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 14:08 New GNU C Library (glibc) security flaw reported on 30 Jan 2024 Turritopsis Dohrnii Teo En Ming
2024-01-31 14:23 ` Xi Ruoyao
2024-01-31 14:55   ` Vincent Lefevre
2024-01-31 15:52     ` Adhemerval Zanella Netto [this message]
2024-01-31 16:23       ` Vincent Lefevre
2024-01-31 16:44         ` Siddhesh Poyarekar
2024-01-31 18:47       ` Xi Ruoyao
2024-02-01  0:51         ` Vincent Lefevre
2024-02-01  1:03           ` Vincent Lefevre
2024-02-01  6:41           ` Xi Ruoyao
2024-02-01  9:07             ` Vincent Lefevre
2024-02-01 19:55               ` Paul Eggert
2024-02-01 21:11                 ` Siddhesh Poyarekar
2024-02-05  0:58                   ` Paul Eggert
2024-02-06 15:00                     ` Zack Weinberg
2024-02-06 21:30                       ` Paul Eggert
2024-02-06 22:04                         ` Xi Ruoyao
2024-02-07 17:07                         ` Zack Weinberg
2024-02-07 19:55                           ` Alexander Monakov
2024-02-07 20:45                             ` Zack Weinberg
2024-02-07 21:53                               ` Alexander Monakov
2024-02-07 22:56                               ` Paul Eggert
2024-04-06 17:17                           ` Paul Eggert
2024-04-08  8:28                             ` Florian Weimer
2024-04-22 14:39                               ` Zack Weinberg
2024-04-23 18:09                                 ` Paul Eggert
2024-04-23 18:26                                   ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c622583d-a7f5-45ad-8195-0d8238469823@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=ceo@teo-en-ming-corp.com \
    --cc=libc-alpha@sourceware.org \
    --cc=teo.en.ming@protonmail.com \
    --cc=vincent@vinc17.net \
    --cc=xry111@xry111.site \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).