From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id DB8973858C66 for ; Tue, 6 Feb 2024 22:04:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB8973858C66 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DB8973858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707257084; cv=none; b=dBsI8K1/fOcXncslHaAy4KqJVKX6/voCA01D6N/fZrIKKVazE7JMLoLa0oeQAFEx65Mb/PcntILA+2EKqSgGZdMWv/V1v9L82i5DVTc8ZwYZFQQpnU1yVi/0IX97vqjJEkC5ENyAmySLJA0jCn1CvUUXfHZWSBVv4rGtK2jEHlI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707257084; c=relaxed/simple; bh=TZAunK6qq011535i0S6pjCzewzl6oSkjvos4ITCjzZQ=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=B49QnT/JNIjUf+xUhukWpxEglX49ayAMyNbsuoYEoWl2Cs6BAqe8wLyuJPswzTOYjlpJbB2I2FwoWBiKkvar8nXvWjyMbOq4IUDX9Prj9E+r0VpUWh4MTuCRx/KJRkdRrL7vDVsw/TLA9vwY4yqNIbNuTK3+/pT0ofLJ1vZLMTk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1707257081; bh=TZAunK6qq011535i0S6pjCzewzl6oSkjvos4ITCjzZQ=; h=Subject:From:To:Date:In-Reply-To:References:From; b=B5d384e1FrfRJIpGlWE0BMqppiEOw0lCWGZfyK17Dz/UjOg05VdyZrVigbGmCkDw9 CP5Pmam2ugC0SS03W/sjTj4UoyZghSy/IJi85ppMXVMRjsEb+g+xCTzrctcOlJwgzO xm8aUgVF6bNYILF6ITjMXyy8LwWU0HSgH+dv+DgE= Received: from [IPv6:240e:358:1145:1f00:dc73:854d:832e:4] (unknown [IPv6:240e:358:1145:1f00:dc73:854d:832e:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id E3EDD659B4; Tue, 6 Feb 2024 17:04:36 -0500 (EST) Message-ID: Subject: Re: New GNU C Library (glibc) security flaw reported on 30 Jan 2024 From: Xi Ruoyao To: Paul Eggert , Zack Weinberg , Siddhesh Poyarekar , Vincent Lefevre , Adhemerval Zanella , Turritopsis Dohrnii Teo En Ming , GNU libc development , "ceo@teo-en-ming-corp.com" Date: Wed, 07 Feb 2024 06:04:31 +0800 In-Reply-To: References: <20240131145555.GB2102@cventin.lip.ens-lyon.fr> <96521764f4636c9ea3f3089f369975c12fa8be77.camel@xry111.site> <20240201005155.GF3044@qaa.vinc17.org> <20240201090721.GH3044@qaa.vinc17.org> <5ea9eabb-f047-490f-abe9-43630d79c395@cs.ucla.edu> <7234533a-c8dd-4114-aa64-d4af3b138a3a@gotplt.org> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.3 MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_MANYTO,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 2024-02-06 at 13:30 -0800, Paul Eggert wrote: > On 2/6/24 07:00, Zack Weinberg wrote: >=20 > > This sentence only makes sense to me because of what you said in the > > cover letter, about the array not being required to be totally > > ordered.=C2=A0 I=E2=80=99d like to suggest instead >=20 > Good point about saying explicitly that the array need not be sorted. We= =20 > can add "Although the @var{array} need not be completely sorted,". Done= =20 > in the attached revised patch. >=20 > However, the paraphrase you sent was too generous, as it allowed the=20 > array to be in completely random order if it had no matching element.=20 > Although I think glibc bsearch works in that case, we're likely better > off sticking with POSIXish wording. >=20 >=20 > > Not related to what you wrote, but: A later paragraph says =E2=80=9Cthe= object > > addresses passed to the comparison function lie within the array,=E2=80= =9D > > and C2011 7.22.5p2 actually makes this a hard requirement: =E2=80=9CThe > > implementation shall ensure that both arguments [of the comparison > > function called by qsort] are pointers to elements of the array.=E2=80= =9D > > It looks to me like there are situations where our implementation > > doesn=E2=80=99t do this: >=20 > I don't see that in the glibc source. Are you sure about that? >=20 > If glibc qsort passes addresses outside the array to the comparison=20 > function, then it's busted and should get fixed. I don't see this in Glibc 2.39 either. I've run some test cases with assertions in compare fn and the assertion has never alarmed. And the developers were well aware of this standard requirement writing the current qsort implementation: https://sourceware.org/pipermail/libc-alpha/2024-January/154001.html --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University