From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic308-18.consmr.mail.ir2.yahoo.com (sonic308-18.consmr.mail.ir2.yahoo.com [77.238.178.146]) by sourceware.org (Postfix) with ESMTPS id 67468384A033 for ; Mon, 27 Apr 2020 20:29:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 67468384A033 X-YMail-OSG: 5eJU.2sVM1lvKla1ho8nBxvbFQn2tlcI8Dchq9X7_v5W.V8A1EgUETJHR17Klgt y50DGN7OScMA1JBRmXJ_yYHMN86_ZLMKyRb.Ep5ykGPN8c2P_lsy7hUzFEVoXOcDYM8hIBgMeUdo tQ.jBV3VcRcgYfp.whdjDmpQImxKAOKJoefRm8AtssRvVIbRjPgSneoiz1K.18hQQTPBR3YGbjGP CVsU99HYL9MJdJgv.6lMmcMGJsoUiO8UBbaqd.XviQwMm3hbpgmOyFoxxZFvIeL2yHZ9dqZMsrat ZP9O6i1VfkmLq1JbNf25HHM3kLJHSYTlF33KdDcTw_2vgMeb1_1jPeY4fb.liiy17WMvfO0uERUG 4EdaN7cNgcwLObgf4lD5diVwT8ySWqm_jMtQmDKRJV3ZC.bI2LvsYeNDlZpsxUhSSmVH4UuaTouv .g5zZMq7x.67rKD6J9wpp9gW32DO5WLvjfq.Ixm1kdwzT8w_fFlE6IrPw4qpMQKtZLg5tww3vHyP F.1Oqw2vJJXGOKPmgY6GJvPO5PMnxThYL0NfNbYyzUy3tTTzBNAkFvbb7HPjvdr9Tv4tnchS2sma 4YZafOnhSPgh0ELa31hjy3wVSIlLX6.SWRArJdg3H_zRmqBSLVE.kvqAT..fsQ8h22gQzQYPSk1B KL3Txp4b2cJJgeqPNE6QcTyaCsBkkwvIOMPFmD.27nAglqpfr0jcvB.0tkr3AKfKXU01zRpAF1n3 MSkZahCOpj4KYNxrJxsDEEatwin13Xm5khlPI9Lu8yRZ5A53daE.ulYgU.jB5PMugBvi4tVIjJwn 2ID76EJbzx51_Bg9hk7hdbvplJqvdAphbJdUBPuEJoonZV4J2UX5S4wy3Q.KNMlMBClM1538O4Yk aB.o3oWwjHDkzOqWXCFIj7Z.b64I5JiOMVAoJXfYjxM0kU7Lg.uJGqKwrZh2kjf_maLjNwuM2o5o T4zjDfZM8RxnnYNO5_e5e2yoQaJFBsSkpr5RSTmhjlk2zNyw2vQCOVd1i5k8c6HHlST.l2rr4uO. xEBMHOwRho34R576qOfkTMaO123l39vi0QVLw2I0XMJjf4pHyCKIgIPShJRJ3dXS7hY37jy01UUm vqltCYnkYjAkUVxka.jin5LQkcCoT7z06gHqC09u9.LqnCA9uQZErhjlYQnJOxk8Wg0gf6cp6NtN IR3BM_TlMe5RyIukR.fTOykCXdjToqASE98IAnO.uCSX1K6V706eL6_PczCoUdIfr0BHsyU39Uew WMQ3_3LeaQivICC0CaQr5.tWlT08boi7o7g16skUgJ.Liquk7goJFkuVNwDXhhlsI4cJ3ILQZ_to ChRouKpM37lmCCfNNTVzIFLdKXn51cGSUIXdI5Xc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ir2.yahoo.com with HTTP; Mon, 27 Apr 2020 20:29:09 +0000 Date: Mon, 27 Apr 2020 20:29:08 +0000 (UTC) From: "R. Diez" To: Jeff Johnston Cc: "newlib@sourceware.org" Message-ID: <1918742529.2295153.1588019348307@mail.yahoo.com> In-Reply-To: References: <989180140.2023825.1588003097077.ref@mail.yahoo.com> <989180140.2023825.1588003097077@mail.yahoo.com> Subject: Re: _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.15756 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 20:29:11 -0000 > The code does not disable via NDEBUG because it is a fix for a CVE. > It is not (and should not be) tied to user control over usage of the asse= rt macro. > [...] First of all, thanks for you quick answer. I guess you mean CVE-2019-14871. The "fix" for this CVE feels wrong. It seems that you are trading accessing= a NULL pointer with a total firmware crash. I believe that there is no oth= er way that __assert_func() could behave to "fix" this problem. Well, that = is trading a security problem for a denial of service problem. This is not = really properly fixing the problem. Firstly, is there no other routine to abort the firmware? __assert_func() s= hould only be used together with assert(). Is it documented anywhere that _= _assert_func() must stop execution in order to prevent a security hole? Is there a way to avoid malloc() at all at a place where the user does not = expect for it to happen? For example, preallocating all memory that might b= e needed. If may be worth the trade-off space vs safety. Like I said, my firmware does not use threads at all. Is there a way to dro= p all these reentrancy stuff? I am already using --disable-newlib-multithre= ad . In any case, I though the assertion message "REENT malloc succeeded" is wro= ng, it should probably read "REENT malloc failed". Or am I reading the code= wrong? Thanks again, =C2=A0 rdiez =C2=A0newlib-3.3.0/newlib/libc/stdlib/rand.c:78: undefined reference to `__= assert_func' >=20 > I tracked it down to this definition: >=20 > /* Specify how to handle reent_check malloc failures. */ > #ifdef _REENT_CHECK_VERIFY > #include > #define __reent_assert(x) ((x) ? (void)0 : __assert_func(__FILE__, __LINE= __, (char *)0, "REENT malloc succeeded")) > #else > #define __reent_assert(x) ((void)0) > #endif >=20 > This is unfortunate. First of all, I wonder what happens if malloc fails = and there is no assert. Will there be a crash? >=20 > Then, I would like to assert() in debug builds, and not in release builds= . My code does not define __assert_func in release builds, because assertio= ns are only supposed to work if NDEBUG is not defined. That has been workin= g fine for years, until this Newlib version. >=20 > I am configuring Newlib with --disable-newlib-multithread , because my em= bedded firmware has no threads. But I guess I still have to deal with "stru= ct _reent", don't I? I would have hoped that, in this single-thread situati= on, any reentrancy structure could be allocated statically. Or is there any= way to avoid this malloc()? >=20 > Thanks in advance, > =C2=A0 rdiez >=20 >=20