public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Joseph Myers <jsm28@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc] Avoid use of atoi in malloc
Date: Thu, 22 Dec 2022 19:37:26 +0000 (GMT)	[thread overview]
Message-ID: <20221222193726.729733858425@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c923cd8c496c7f253f327361a65c737233c7ebbd

commit c923cd8c496c7f253f327361a65c737233c7ebbd
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Dec 22 19:37:09 2022 +0000

    Avoid use of atoi in malloc
    
    This patch is analogous to commit
    a3708cf6b0a5a68e2ed1ce3db28a03ed21d368d2.
    
    atoi has undefined behavior on out-of-range input, which makes it
    problematic to use anywhere in glibc that might be processing input
    out-of-range for atoi but not specified to produce undefined behavior
    for the function calling atoi.  In conjunction with the C2x strtol
    changes, use of atoi in libc can also result in localplt test failures
    because the redirection for strtol does not interact properly with the
    libc_hidden_proto call for __isoc23_strtol for the call in the inline
    atoi implementation.
    
    In malloc/arena.c, this issue shows up for atoi calls that are only
    compiled for --disable-tunables (thus with the
    x86_64-linux-gnu-minimal configuration of build-many-glibcs.py, for
    example).  Change those atoi calls to use strtol directly, as in the
    previous such changes.
    
    Tested for x86_64 (--disable-tunables).

Diff:
---
 malloc/arena.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/malloc/arena.c b/malloc/arena.c
index f381f18371..840129e956 100644
--- a/malloc/arena.c
+++ b/malloc/arena.c
@@ -386,34 +386,39 @@ ptmalloc_init (void)
               if (!__builtin_expect (__libc_enable_secure, 0))
                 {
                   if (memcmp (envline, "TOP_PAD_", 8) == 0)
-                    __libc_mallopt (M_TOP_PAD, atoi (&envline[9]));
+                    __libc_mallopt (M_TOP_PAD, strtol (&envline[9], NULL, 10));
                   else if (memcmp (envline, "PERTURB_", 8) == 0)
-                    __libc_mallopt (M_PERTURB, atoi (&envline[9]));
+                    __libc_mallopt (M_PERTURB, strtol (&envline[9], NULL, 10));
                 }
               break;
             case 9:
               if (!__builtin_expect (__libc_enable_secure, 0))
                 {
                   if (memcmp (envline, "MMAP_MAX_", 9) == 0)
-                    __libc_mallopt (M_MMAP_MAX, atoi (&envline[10]));
+                    __libc_mallopt (M_MMAP_MAX, strtol (&envline[10],
+							NULL, 10));
                   else if (memcmp (envline, "ARENA_MAX", 9) == 0)
-                    __libc_mallopt (M_ARENA_MAX, atoi (&envline[10]));
+                    __libc_mallopt (M_ARENA_MAX, strtol (&envline[10],
+							 NULL, 10));
                 }
               break;
             case 10:
               if (!__builtin_expect (__libc_enable_secure, 0))
                 {
                   if (memcmp (envline, "ARENA_TEST", 10) == 0)
-                    __libc_mallopt (M_ARENA_TEST, atoi (&envline[11]));
+                    __libc_mallopt (M_ARENA_TEST, strtol (&envline[11],
+							  NULL, 10));
                 }
               break;
             case 15:
               if (!__builtin_expect (__libc_enable_secure, 0))
                 {
                   if (memcmp (envline, "TRIM_THRESHOLD_", 15) == 0)
-                    __libc_mallopt (M_TRIM_THRESHOLD, atoi (&envline[16]));
+                    __libc_mallopt (M_TRIM_THRESHOLD, strtol (&envline[16],
+							      NULL, 10));
                   else if (memcmp (envline, "MMAP_THRESHOLD_", 15) == 0)
-                    __libc_mallopt (M_MMAP_THRESHOLD, atoi (&envline[16]));
+                    __libc_mallopt (M_MMAP_THRESHOLD, strtol (&envline[16],
+							      NULL, 10));
                 }
               break;
             default:

                 reply	other threads:[~2022-12-22 19:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221222193726.729733858425@sourceware.org \
    --to=jsm28@sourceware.org \
    --cc=glibc-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).