From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id B5C2E3858438 for ; Wed, 7 Feb 2024 19:55:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B5C2E3858438 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B5C2E3858438 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=83.149.199.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707335729; cv=none; b=su7sKVh2Mp+Wld3o8eY8mpmeCv7U5Aqd/3px71rX/XDeYNIjVLxT1rfWFJSXjJz/58z0Z/+bUHsj8vWPPQUQslleGqKNyjOvgTDcX/YOZBh51aY7RqZfGKxBhiFfGjawnRKR2kgFiQHQhMWwYJG/bdiXh3eqjZFS5MoNCbIs9qw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707335729; c=relaxed/simple; bh=Jm2qGDfGJ6dlh8/zdIUcEIirtYm7JW3/ZN6FXDqC2s4=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=uidllFDtEF6iZ0fVgYQpZDWOvapMdbq6MQzRxYGN3exjJAmcnGmAzPHCPQSRZTY53vFSnnW/CbZOhx8KBXauWFVuri9u3/6mWB8SQ1qEiTf2Vem4oh2qQ4E8esc3uHnhLwnviuQFV0ms1ZSxs6EofeFdVX81n8Ln3CDWlEb71Ow= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 9993940F1DEF; Wed, 7 Feb 2024 19:55:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 9993940F1DEF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1707335725; bh=qaDoNsftOSazJQe5T3LhPRx/7WIHphJny0xf7R+vkJQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=f6aXAFbrYPM9z+KL9+7KB5U+DnrBuHpF9wvRXZ85YhDNaxJiM8WcT6Ei3TdOF+pnN PVLzIlR+xo6cC0nLcNLUbJI/SHLoSg5V3jWEx90BxaHPz1Thqbjhw7R/HqytrtSrp3 dKLbrg2va/kq2nlVZ/iUbK+t8RTfKY6aJGQatJuA= Date: Wed, 7 Feb 2024 22:55:25 +0300 (MSK) From: Alexander Monakov To: Zack Weinberg cc: Paul Eggert , Siddhesh Poyarekar , Vincent Lefevre , Xi Ruoyao , Adhemerval Zanella , Turritopsis Dohrnii Teo En Ming , GNU libc development , "ceo@teo-en-ming-corp.com" Subject: Re: New GNU C Library (glibc) security flaw reported on 30 Jan 2024 In-Reply-To: <4d94a528-fe3f-413d-afa0-91a41f8371ff@app.fastmail.com> Message-ID: <4963e3ae-b0d5-d1d7-a986-5709d7a30bbb@ispras.ru> 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> <4d94a528-fe3f-413d-afa0-91a41f8371ff@app.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-89138227-1707335725=:11006" X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-89138227-1707335725=:11006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Wed, 7 Feb 2024, Zack Weinberg wrote: > >> and C2011 7.22.5p2 actually makes this a hard requirement: “The > >> implementation shall ensure that both arguments [of the comparison > >> function called by qsort] are pointers to elements of the array.” > >> It looks to me like there are situations where our implementation > >> doesn’t do this: > > > > I don't see that in the glibc source. Are you sure about that? > > I was wrong about this; I misread the code in qsort.c. Specifically, > I missed that msort_with_tmp always merges *from* two subsets of the > main array, *into* the temporary array, and then copies the result back > to the main array. Still, I think it is likely that some C libraries in > the past have failed to implement this requirement (intentionally or not). > In the attached patch I revised that suggestion again and I hope it satisfies > everyone's expectations now. I don't understand how that is likely: was it common to use merge sort for implementation of qsort? For in-place sorting algorithms that mistake is pretty much impossible to make. In any case it seems unnecessary (and even impolite maybe, towards the authors of those other C libraries) to make such implication in the Glibc manual. It's much nicer to stick to the facts about Glibc itself. (Glibc VCS briefly carried an implementation with such a mistake around 2002 when Roger Sayle's "Towers of Hanoi merge sort" was applied and then reverted) Alexander --8323328-89138227-1707335725=:11006--