From nobody Fri Jan 07 22:28:47 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 0C38019465F0 for ; Fri, 7 Jan 2022 22:29:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4JVyYm5N4mz3HyM for ; Fri, 7 Jan 2022 22:29:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641594533; bh=ivwdvp6RRxVYDUoe2+qHMuiQvdWfmHDheioyB26lAxU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UVkQaRRJYdPDnIE2lxBpfK9haWS21iOcyw+6EQAVfG1NV88dPu1oMclxXJ0gJNVYpMpsn1m9Yxm0sNzXcpYyF7HCOXt7tXRO7i4xmojuX3lLU+KleHek2X/ZgeZpxqwyHBY8aX57DZIvCRXhV1p3o7KRkFKt1xEzm7HJyuoavNdDcVyEvkboTej3TYUG/EA3WPBzhK16FhmI7fyCPTNtgfxGvUoGuT55X/X7trK5rbjJv2HofU/Q3aK0olHtTIzSd3awGusVihK3ksWaZ5yLgcBLNGHFEhy1pdqfsa4OKFTC0msnaMeXhHob5nQoxlPFlmmhIWHgPNaLh01xVz8YNg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641594533; bh=YSGd0qXlH1AzkXGJTcycAga/VVatCzG3WvDPsbiJLqw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iHeS2w+6m9UynVQfREZ6lJnicJXNAGnd4Mt12UM5/cDLi6zqJDHkQOKFbFsfviMbTsd/ydc5AFy52NK1LzETNySBeEW0M5WodSM40oD0kxAczi4khulpTzgOI4aSqYuPGhrlf1E5OwI6lS/FsQ1gMXUbyb2DtuCHfUvEcymza0Kk3+pEBs0T8sECOn+OzJSJ+f4LdpBIHdq5RX88fUqhW/kpAg1QfWLo2WEK/e6d+M0MqGbd2qCq+jAP+Gp9zxpXWYgQYQQjNoCuW24l2N+1bz9W/KZeq5fIe5h2cdFkvO8WmAvVVqV1Dp496du3uk1ieQujpUVZKafaY9HKj2O7yA== X-YMail-OSG: gzG2EDwVM1nb6ciiBjNBbMMbr.FKlh3pnXrycauPvNGA0FaTPht1X_ju_azv2e7 HJlvIyNQTb5dU5lwsQercOmOCERtij2DdVxY7.cYXIRlkpwrKnIAAUeNKaNEf6k6E0nhtKCemghk fs45HQ9GYSMFM9M_1OCE6QT9CC0ZJusWcy5fFQY8Kqw6eAS5Fm8dHSqV18lZv.yDs3wPFAcqgFHc VKkEum6RcGew7YJiJTJqnI7wpmEk8ofinPK2GDobRyRbDZxLVy1q5SbD92wKGWLDXs4Sv_2JsQWI 7oyDNyHgfUB2toh1QkTa5O9NQ9Z5qxSHkrqV0kEF4L5kzXfbF0dvGxmy49DyDzwHyYnt9aqyf6PJ 4qu3N2z7tGX7hRdCRkMC9hGvvdBk4e7uowPbFFlNe9deA9zmv9HF7zZPfNMwanCVGuteXtQNAINi AquutmaSd2.KjGUFRjPt8pe9cPhTdIS7YY..BtG1Vd2UMunGO9zXnJIurE6k7_UtAlDL9.ckGyAP 4MccXjy_XpUmDkckq.pJxEXQ_sHesM_lUaJJuCgiWHiwG.nGflqe9ZUfXy5Gfwg0NHExTBkygpfP zDTaICjUyQ8hw7CSw_ynsStNuY.PnZgWqk3.znhKaWPztmOWrgA2CqatvJmg9Pmbt3G9hrRk58Jk cPuRLER3lhIWUP11mgBxWL8V4XmdKgeiGlfLIK4ZaATd4q_UF5UsxmCrHRe_bI0iD1KQbIdB_fW4 0CN7vhtlpjcN8XsY0zOtuD9HVbQpZEgc2vpXU5DsGqD7lSWjcCaM5eT4jeapltTRRPcCsZQgnMBK cUO6tGIM9HhL3NbOOBFxN33dthMrZa8gAX2RAbKLcyxCY0t1ZEUWt00CaRN52CCl7m98F5CVPLOa kldNzCokpNUXR8Q7a47b6uIfuLoWSQi9GtXbO0Tp528yxXbf1LMWimf4ajsl2mNtVXXQn17FPDC5 d9CXa9kr6rURPlM27s4IPjtklhnBzYLz0n8VV8n2M9djCXw6PCAHloXenFEux0ay7OpJar6QRcBh vYn.v8jn8Wrsaz4dRMR58y.UsiaTt2IB.fYrIjpsA_8_tW3nBrd.yi3qS5hyghqU2LeTAxE.tabn S6ii8h7jJuYVLR3yYjM3l5YprPL_2r36nBYpoL6d_ycn4LgbLY572VcgmMysqrVfe.hCG4rGuu0_ 1FwtKYH.xpDNRs3JdPtGWaTwIfRZ8tqCeOFAfBkEj5Ay37IBnPwCdHR1p3mb6n_iNoC3UQTIpnSy C3D2xLr8mx_Uv0ZyxTxjLugw2iZc6C4kj2VUlOnSjel1WNLrD.zhQ4iYHlN8HhLKdLg_gQM83fmG YsB40_CcKRjjQT.pvBbEwITZnnzG9V7hlK6md8xbGSXGNIpPSvvo98RHqKO806Xc28Yvtk_gmChK ifQRTgh9c8mqza5nhd2rGydQn9_GWCISBqotbV.0R91KvMfPUXYkWmNQmTZ1caMJqo0DwIseuBla rY7XNS3R0UEJkiAoGID4THyEwYqA3rRq9SxRw.4aMIyKgW7JQgB_qBw2EkdgurnEwfFwBnVC05on 1qkNLJzYDjFO.B4Me95aqMGBbqBY10TtFiQIpAusEk.VR3UfatyxDc85rIlhyrE3t2ugZk.Ff8Mm OI5UB6.iEGqN9H4nBEW9DFF4LrQ7LdHokrZpo7rl2HrcrgQ8pIa2YKVlHpIhTjinjwYhIRK1ePIE KpzPAfRcf0ZnmPrZfyc6SlT3yFmS8Ya_wUjHo5QaKdVVAuMcEZbFhuasfP8cDB07RXRZ5th_3M2r wjGK5ZO2e3x1CvxOMbVn2nVMukzEt7x1GVZMacK3EDxMDVUGXVzJOYt5XFLgcsTLO0bj5UCWOBtP Shr4IPIj087vRv58J5Ynjp553T2TiBUYZtpdV48qvv.duwNR3b9r5ZaiBu2UVhHFPcNOJdw63zFC K0e4FB7XVnGgRlyJ2p.KOWXYOdzrW24GwXTHlzcBeLb7QxLNOdBl1.WLV6vta_ecRAp9ffNy1h67 Tjw9_vl0jnJW_hMmW1J86D.xB7LVhuzPPTQ.lTiP7oEPgJEQ15yr7UE9GxhDVCtr_EXD7Ttl0AC. bWR6Y8T7CHNH0tg9JwT8ucqFK.xT2iTVKqDYRN8x9SMuSw6yDz9hxentVxV0r0HHjM178h.EhJap D3ekX_VgLhD1CbXBMK1Dj6OiYYZLf_2Wq3u0auF6r.CxVmnXFohg8kpp4enErRtTW7cyf0FbJb9x VKsQjQK4gJ6gW_sMkF2TZpDFWe1zU19_NedVYOqJXLCZkmAtwVdZ0bzl3xkMXLfotbCjsCBFmPrA HC8xWTbA7SAlWykVi X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Jan 2022 22:28:53 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 14737cf4c348bad4fbc1d1ad423c217a; Fri, 07 Jan 2022 22:28:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile From: Mark Millard In-Reply-To: <1fb8db3d-3d12-68ab-95d6-5f6e01af49f3@FreeBSD.org> Date: Fri, 7 Jan 2022 14:28:47 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <453B3366-AED7-4F29-BC29-A880FA982E56@yahoo.com> References: <1fb8db3d-3d12-68ab-95d6-5f6e01af49f3@FreeBSD.org> To: Stefan Esser X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JVyYm5N4mz3HyM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-7, at 04:31, Stefan Esser wrote: > Am 07.01.22 um 12:49 schrieb Mark Millard: >> Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D >> after finding what to control to allow the build, I installed >> it in a directory tree for chroot use and have >> "kyua test -k /usr/tests/Kyuafile" running. >>=20 >> I see evidence of various examples of one type of undefined >> behavior: "applying zero offset to null pointer" >>=20 >> # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt=20= >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/sed/process.c:715:18 in=20 >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> Fail: stderr not empty >> --- /dev/null 2022-01-07 10:29:57.182903000 +0000 >> +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr 2022-01-07 = 10:29:57.173100000 +0000 >> @@ -0,0 +1,2 @@ >> +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> Files left in work directory after failure: mntpt, mounterr >>=20 >>=20 >> In general the lib/libc/stdio/fread.c:133:10 example seems to >> be in a place that would make it fairly common. >=20 > Interesting find: >=20 > while (resid > (r =3D fp->_r)) { > (void)memcpy((void *)p, (void *)fp->_p, (size_t)r); > fp->_p +=3D r; /* line 133 */ > /* fp->_r =3D 0 ... done in __srefill */ > p +=3D r; > resid -=3D r; >=20 > If fp->_p =3D=3D NULL in line 133, then NULL has been passed as source = address > in memcpy() in the line above, and I'd think that is undefined = behavior, > even if a length of 0 is passed at the same time. My copy of ISO/IEC 9899:2011 (E) only explicitly mentions such a limitation for the memcpy_s variant. It does say "[t]he memcpy function returns the value of s1". The only mentioned "behavior is undefined" is for copying between objects that overlap. But there is more general wording in 7.24.1 (of 7.24 String handling ): QUOTE Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call still shall have valid values, as described in 7.1.4. On such a call, . . . a function that copies characters copies zero characters. END QUOTE But I've not noticed anything in 7.1.4 is that explicit about NULL arguments with zero sizes or that bans NULL arguments in any generality. In other words, I believe that the lack of a report for memcpy's argument values is consistent with what ISO/IEC 9899:2011 is explicit about for such things. I've not tried going through POSIX material or any other potential standards. > Maybe the code block quoted above (line 132 to 136) should be made = wrapped > into "if (r > 0) {}"? >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com