From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id CDBD338930D3 for ; Wed, 29 Apr 2020 19:51:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CDBD338930D3 Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-309-_I3GaFtqOASBVCU8WPwxUg-1; Wed, 29 Apr 2020 15:51:38 -0400 X-MC-Unique: _I3GaFtqOASBVCU8WPwxUg-1 Received: by mail-pf1-f198.google.com with SMTP id 67so3006098pfe.0 for ; Wed, 29 Apr 2020 12:51:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Il31Ma7CvliS7TwdPsoZcnKjB4prWQHQIb2PvImKiq0=; b=CJRvHtQHxdbv4YL1WwOxMGLXNjZXtkP1i8f0HMcX+9yXMEvSwWcWD+N+RoSj1iUTm1 N67+xXatjeXwwicfM90VObFgtCpM6zrzNTfRSIrF6Ih+ZctO7g2RAyPA5EnrpVJN2STc zEY0k1Z+H4h45O6lktHd3FdBhn5Hpu68a8FMaltpsOt2TyI+QfXaUufi5x4TsMLA/nns L7cuRBtuhXWgmTm51PmEVDcPKUwtFYpMDaEcAlYM8Jmr99cd5QGzmj0inJLreJ5qm4At f8gXUVDU1TyJJw9pspoiPg0tErLTAhUgCxpem+VnsC/UayGWh06k+g6kjqjAQDnr+f2I 2nKw== X-Gm-Message-State: AGi0PuagT2KP+mRnbkZ9Z63htP2geJBfaqDWj/t9EOideRl+aocXh32r fxPdZH3oYnLE0wwV3ZUoZbk/zCrI4krCdUa2jOJXm25txhLw8DP15ywYTHW2fa0oPKMGhsF9e2F JuryDLqc4yDhBaOj0UjaTEOc4AizybeI= X-Received: by 2002:a62:81c1:: with SMTP id t184mr18905246pfd.236.1588189896543; Wed, 29 Apr 2020 12:51:36 -0700 (PDT) X-Google-Smtp-Source: APiQypK/Lz2HPQvs54cOdKzJ5enRiir96NOQplsAaAubE2Hb6ZnqsSTMV0BK+DcFl1fOGf9lVh/C54I5uOejXr51j20= X-Received: by 2002:a62:81c1:: with SMTP id t184mr18905223pfd.236.1588189896224; Wed, 29 Apr 2020 12:51:36 -0700 (PDT) MIME-Version: 1.0 References: <989180140.2023825.1588003097077.ref@mail.yahoo.com> <989180140.2023825.1588003097077@mail.yahoo.com> <1918742529.2295153.1588019348307@mail.yahoo.com> <1949956947.2883373.1588075584956@mail.yahoo.com> In-Reply-To: <1949956947.2883373.1588075584956@mail.yahoo.com> From: Jeff Johnston Date: Wed, 29 Apr 2020 15:51:25 -0400 Message-ID: Subject: Re: _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined To: "R. Diez" Cc: "newlib@sourceware.org" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 29 Apr 2020 19:51:53 -0000 On Tue, Apr 28, 2020 at 8:06 AM R. Diez wrote: > > An alternative change would require modifications to all the > > existing conversion routines using eBalloc() and their callers > > to do checking of return values and bubble up to the user, > > setting errno to ENOMEM. > > I am not sure what conversion routines you are referring to. I found this > issue with rand(), because lwIP needs a source of random numbers. It is > normally not expected that rand() calls malloc(). rand() returns no error > indication, according to the POSIX standard: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html > > So using errno here is difficult. > > rand() ends up calling _REENT_CHECK, which does a malloc(). What do you > mean with eBalloc()? > Sorry, my bad for the confusion. eBalloc() was one part of the CVE whereby newlib was allocating memory internally for the conversion routines and not checking the result (this code originally came from NetBSD originally and assumed the Balloc() would succeed or a NULL pointer access would occur). To make this return gracefully to the user without an abort would require a number of changes to intermediate routines. Regarding the _REENT_CHECK_VERIFY macro, this only affects you if you are using _REENT_SMALL. With that set-up, the reentrant structure is minimal to start with and storage is allocated at the last minute, if needed. If you look in libc/sys/reent.h you will see that for the non _REENT_SMALL configuration, the storage is allocated up front and the _REENT_CHECK macros do nothing. In your case, rand() calls the _REENT_CHECK_RAND48() macro which for _REENT_SMALL will end up allocating the rand48 storage if not already allocated. So, you have a number of choices: 1. don't use _REENT_SMALL and rand() won't allocate storage when used 2. use _REENT_SMALL but call rand() at the start of your application so it won't try to allocate memory later on 3. use _REENT_SMALL and ensure you have enough extra storage allocated to handle the apps needs and the minimal storage needed for the rand48 logic 4. allow the abort or null pointer access to occur and tune the application not to run into this scenario if it does happen > > > The memory in question is being allocated by Balloc() > > which is part of the mprec.c solution used in newlib. > > The allocated _REENT_MP_FREELIST has an array > > of storage to reuse for different k values so newlib will reuse > > [...] > > Does that apply in my scenario? I am building Newlib without thread > support. There is no reent creation or destruction, as far as I can tell. > If you aren't directly/indirectly using the mprec routines in stdlib, no, it does not apply to you. A reent structure is always allocated (see impure_data in libc/reent/impure.c). > > I have been digging further, and I believe (the code is not easy to > follow) that these unexpected allocations come from using the "small > reent". What does --enable-newlib-reent-small actually do? The README fil= e > at this location: > > https://sourceware.org/newlib/README > > has this description: > > `--enable-newlib-reent-small' > Enable small reentrant struct support. > Disabled by default. > > But it does not really say what the difference between the normal and > "small" versions is. > The difference is that _REENT_SMALL omits a bunch of reentrant storage used by various routines until they are actually used. Thus, your reentrant structure footprint is the minimum it can be for your application (e.g. if you never call rand(), you don't need the rand48 structure). If you never do file I/O, you don't need the std streams allocated for you and so on. The cost of this is that if your application has run out of memory, you might not have enough for some of these last second allocations. The CVE in question noted that newlib simply attempted to access the reentrant allocated storage without checking and it could be null. That said, if you don't have enough storage for a small reentrant structure need, the application is in serious trouble to continue because many platforms share storage between the stack and the heap (you might not have enough storage for another call). I wouldn't have a lot of faith that an application will check after every call it makes to see if ENOMEM is set and then magically remove some storage it didn't really need. Such a case usually means either tinkering with the initial storage available or tuning the application so it isn't wasting storage needlessly. Regards, -- Jeff J. > Thanks in advance, > rdiez > >