From nobody Wed Jan 12 11:00:31 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B867A19455F6 for ; Wed, 12 Jan 2022 11:00:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYl3H3G56z3JKt for ; Wed, 12 Jan 2022 11:00:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641985236; bh=vwZmtfS6+3f0Mcdr/wJxOqF7LidKpFYzTrK0WHHTgk8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=phWD23+sEp9tF2HRk7F52K66s2Lxd06GzTBHPXQBqX2iF0ULa3akk+mqeHSFcrIMU4ZWn8y0R/0+8DBDB/PjLZE7GMhJhJU3wJN6S28fArull/BpknJUItaETWojuwzWYeTN1ijsP+o9N8nFQ+XVlIG5T27Xvrlg2pS1eSekUtYolmnQUvcW8IofrgNRmrh00gkhFT0ywsw5VqYDAVQg5d0vpcTkiqPLMnHOVQrIu0KZGgrP6tO5MtWCHQH8QphqSc9Oo4w9dasuDCaOrq6ud2eARfVa+WS3DGWPHut5kIli34vlkFfO6M//LdWKvX8q0zSRYWnn0PsJtJxDkBufvA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641985236; bh=OqxVRVssr46gOGEeNxN1o0TcP+I+xoxxdEoYg0rwpMy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EHH9K91D2JQDMsmC3d4OVb6Agno9q+t3jcdszDQnp9R+Uf6ju03TwhjbcW0zzvCwsl4en4xaOgjVG9G9rErMwBRxTM818PQYP15CMJHpTT/hle8c18YDra1T7GtVLXLMc0CJPWXDS3WrpeS3t3vmoh0HSWrkzY+y4TSKwViXQnV9GIJSZ88UXg4bEHxoEYpkw5qxgO63jG8doAYC7hHQMTM0SJKjLao/bWMQ9tCazAjsKNWG1DYoS8qSJh+Xv12llYHHMvam3yFjxqyCmGmxux8wV2LF74lvvRxe7hNXvkhsm139XN8g4E3GX62CqNv75tBQMDZh4CfcdBcvlAvgcg== X-YMail-OSG: cN1v62kVM1nUPccfPPX2L283hH65GeAeRTOE1j9llndFjZmiYn0LbDchs3js6QI 29uUJDYz7azBMYnwtvLtvKbF1BDsoIyPsP33tIR4bL8VV0UDGJ.jne7WKXs.RBDShDb81JRSGBKp Nz1bA2r3cnSUBP3EgsfBmqlv2zWZWoOxhFkNRyBpRrAgDIQ63N0Ac5ZlUGCERHA.a2SpL08V9G33 whebvVK_JlZF4MeH.ps8WW_x5AEcuQ0FVm_XSv_aD5BdQS2817nU1tUJ0fHVCmi6aCfGa2paheJi bRBOpXYVV6c81gqVBgMws0WYEZXrQukdXp73_f1bbGk.oh1y3.VWR4.bhBwuaey1DjHLGvQuI9ru XfiWq2ImfDE7FmF5fxb9f8jm8kqydq8GvpRmDjczLfdRBDrICy6kByOhsqMLUlKoTzlgve1xp0gU bEIjvSjBlsibhCTjWzWxYD16uJIGwN_b6I2PfnlJVMtYBov0pPeyZyOInfskaH.oRjiPOkwlhTO5 kkJnJv66CXZSkBJir_4y5AjHQYAmV1RIbfld7OMZ_FLRiPBr8qYwzVUjh7jW2GkKEs2ZKVHaWmjT 3_ZDvuCxdkiXMmTwFjDwm6c9joB3krqsw2Ceh34AnSrQ5im9TBZlAaZIh51aYA42WHP26hfcOoyK 7VTUynTip1QDQ9Dixy.ODCj.tjfnZolSJHaUhR_lb4rtiIXhkdD0Rdq2_q9RrrWRqK0KmxkvBsWi WV94WZBqiMGUvg8I2zu9maPzo9cvrow6Suon7n.D6kFZ3t1KM0cK_b2M_Fm6GJX6biw3JbkCCKuh 2.vQPBKeA39GfR4UU.y.2wH3VfGBsL24m0BfZPBl6zbKW4wrthPQuQIRMFjYH.ENmtF4exQoTKPf _1LeP5MXVIJkLsZLOEoeUcZ5HaWx30_Jkx_6ihMGiZ2iyVoL89kSwnZOM2a_lAjIdMr2RIqkiui_ 8JvEfNiLkLS3NwpDsFcIhbXV7.LKy0AmGUH53Kl_VVbjFQ1FX4T5VS_GQbDh8MqzC8WoFx49NBQA G3BZfHjqunDfo.HemoBGSUWhg9xFsfpslJgqrL2F0o0mxnUwnWoJ8.qBgSo9QCi85CQ.X30YJr8P bdXCZPH4rIueibzOpyy_4yxHW5lCe1udTzFgrPqYhuIs4XPqMB5.EVHmuxuO3hs52N145tsxcBeN N6VgcZ4DCTox_yqgif8uK3z70xpDl31WnTkbt74wLcFXy_YHKEmwOaloFaVgrDSbhS8htqSdUopb rDQnTtoU8RLybUkb4mzdDbZXD4QpkdgfWwDdT5VKQGZ0hOWsuJO2YvWrPcxX14NPbzM9Tk1peB6Z PwtnWjXskEiOq8mUGhS42G35JzRi2.2hS.8ebFJS9mnak_UA3c0HUf7HVsBBJce0f7o07h5jYrWU 75xIGAgJ5sSzrEVu2hgjABllOW4KmeTj4TNMLdlKXFYzubImTlPrSMT36MX3cJ0UhIC6juPyKsc3 UIiu5fijBScgzRWI7t9lU3jg3WKySdv.eSq2_pf2w9XXqVqtUD0wTQ6aCneP1Nyro3MacWWTNEHk F8SmgLjlzGZ8cfYXpXeEOVFkGfNoQ9Xexceuf4Kziu0NQl1ExsvCTxMJGRdkzylmUmT2V4MVIQLK 7sLjAy1pGnSnpGEIQ7pr3fbuO7SN3.Pdg6PuMA_ya_tH.7Qu3DkGefPAfNXJOXjRvscHLA6WqjHZ 4fHvrY9uX7lNJuVB1woDmKGAlrUQO_gpEC9SxN5tNfDD3Dg69CxFzRW4ZnmVS.MHtUxMp5cywetL V1q6WqKamtpgj0McTkyJyn9Nt_vvFkZWvuLkF0qjgY8ugNjOAtInundW1BTz91iJQR.j6EfOV4EL 9q8f1vfI8vOtiA78Pbs8cI0ZFLoQcjkYrmw8PuKOQNddc7sqrFxoJfK132H5YXhH8M557MiGfYgG 01Y84ktZPM9_dQyj7HGs.qawATr8dlXmAO4q4R3myVPMqH21KMdo4ZpteSIwO8dme1oCXkH1LoF0 tAvJsQNjo6YhCaXgqKMxeI9TC51mTEQHPeM1_kT.x4_N71j5.l1sIMSYeziYLcS9uizRNST_fIDQ 57oZrvX2tdIiu.Zjk6Zfui7lg7pd8ZAjKsMXXfSAlkbe902Ds4I4gm7yil7vmB5runDvSUx8R05J UpGVGQd0Ji8TRRBU7e9RErwkej4mJwHXEgkaF8Ln16EmwGvj3WOZxfz0_zKXVL_ip6uSbjIjt4ln .4xBdbnMFrm4afeQa9tChkjH14CaLFXrNvc5Da4zHVGZrTOzlqEq4YbLDt7cB6ZSyrj1mecDITgd dPy6jOZATVV5n X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Jan 2022 11:00:36 +0000 Received: by kubenode536.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6469636441df0579e5b17c462604880f; Wed, 12 Jan 2022 11:00:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c From: Mark Millard In-Reply-To: <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> Date: Wed, 12 Jan 2022 03:00:31 -0800 Cc: Stefan Esser , bugs@openbsd.org, freebsd-current , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: <58A5D64F-1157-410B-90A2-3F5F0D31980D@yahoo.com> References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> To: =?utf-8?Q?Jan_Kokem=C3=BCller?= X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JYl3H3G56z3JKt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-11, at 23:50, Jan Kokem=C3=BCller = wrote: > On 11.01.22 22:08, Stefan Esser wrote: >> diff --git a/lib/libc/stdlib/qsort.c b/lib/libc/stdlib/qsort.c >> index 5016fff7895f..51c41e802330 100644 >> --- a/lib/libc/stdlib/qsort.c >> +++ b/lib/libc/stdlib/qsort.c >> @@ -108,6 +108,8 @@ local_qsort(void *a, size_t n, size_t es, cmp_t = *cmp, void >> *thunk) >> int cmp_result; >> int swap_cnt; >>=20 >> + if (__predict_false(a =3D=3D NULL)) >> + return; >> loop: >> swap_cnt =3D 0; >> if (n < 7) { >>=20 >> This would also work to prevent the NULL pointer arithmetik for >> ports that might also path a =3D=3D NULL and n =3D=3D 0 in certain = cases. >=20 > The UB happens in this line, when "a =3D=3D NULL" and "n =3D=3D 0", = right? >=20 > for (pm =3D (char *)a + es; pm < (char *)a + n * es; pm +=3D es) >=20 > This is arithmetic on a pointer (the NULL pointer) which is not part = of an > array, which is UB. >=20 > Then, wouldn't "if (__predict_false(n =3D=3D 0))" be more appropriate = than checking > for "a =3D=3D NULL" here? Testing for "a =3D=3D NULL" might suppress = UBSAN warnings of > valid bugs, i.e. when "qsort" is called with "a =3D=3D NULL" and "n !=3D= 0". In that > case UBSAN _should_ trigger. >=20 > UBSAN should not trigger when n =3D=3D 0, though. At least, when "a" = does point to > a valid array. But what about the case of "a =3D=3D NULL && n =3D=3D = 0"? Is that deemed > UB? It looks like at least FreeBSD's "qsort_s" implementation says = it's legal. >=20 > a !=3D NULL (pointing to valid array), n !=3D 0 -> "normal" case, no = UB > a !=3D NULL (pointing to valid array), n =3D=3D 0 -> should not = trigger UB, and > doesn't in the current > implementation > a =3D=3D NULL, n =3D=3D 0 -> should not = trigger UB? > (debatable) >=20 > So if "a =3D=3D NULL && n =3D=3D 0" was deemed legal, then there would = be no bug in > "mansearch.c", right? >=20 ISO/IEC 9899:2011 (E) is not explicit about such things for qsort, nor is POSIX as I remember: POSIX states that in cases of disagreement it defers to a C standard, if I remember right. But ISO/IEC 9899:2011 (E) is somewhat explicit for qsort_s: (parameters: base, nmemb, size, and compar in that order) QUOTE If nmemb is not equal to zero, then nether base nor compar shall be a null pointer. END QUOTE But there are no words about nmemb=3D=3D0 relative to either of: base vs. NULL compar vs. NULL So far as I can tell, the implementation is free to treat nmemb=3D=3D0 && (base=3D=3DNULL||compar=3D=3DNULL) as a = "runtime-constraint violation" for qsort_s and to return a non-zero value --or to not do so and return zero. As qsort does not return a value, any rejection of such a combination for qsort would be in a more drastic form, making such an unlikely choice. (qsort is not documented to assign errno either.) So I would expect qsort to avoid involving undefined behavior when nmemb=3D=3D0 && (base=3D=3DNULL||compar=3D=3DNULL) but to not = reject the condition. I do not take doing a well-defined "no-op" as a rejection for my wording here. =3D=3D=3D Mark Millard marklmi at yahoo.com