public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Martin Sebor <msebor@gmail.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] avoid -Wuse-after-free [BZ #26779]
Date: Sat, 15 Jan 2022 18:25:27 -0800	[thread overview]
Message-ID: <c5a4ce27-aaec-5bd0-7402-4faaa9460e11@cs.ucla.edu> (raw)
In-Reply-To: <c9f4a1b4-193e-986c-bc21-5866b9e62e16@gmail.com>

On 1/15/22 16:21, Martin Sebor via Libc-alpha wrote:

> +		      intptr_t ip_new_pool = (intptr_t)new_pool;
> +		      intptr_t ptr_diff = ip_new_pool - ip_string_space;

This sort of thing can have undefined behavior due to signed integer 
overflow. To avoid that problem on glibc platforms, you can use 
uintptr_t instead of intptr_t.

> -			      map[i].alias += new_pool - string_space;
> -			      map[i].value += new_pool - string_space;
> +			      map[i].alias += ptr_diff;
> +			      map[i].value += ptr_diff;

Although this might pacify GCC 12, it continues to have the undefined 
behavior that GCC is evidently warning about, since the old values of 
map[i].alias and map[i].value have been freed and this means programs 
cannot use those pointers even if only to add something to them. It's 
conceivable that future GCC versions will figure this out and generate 
code that doesn't do what we want here.

One simple workaround would be for the .alias and .value components to 
be offsets into the storage pool, instead of being absolute pointers.

> --- a/stdlib/setenv.c
> +++ b/stdlib/setenv.c
> @@ -150,7 +150,9 @@ __add_to_environ (const char *name, const char *value, const char *combined,
>      {
>        char **new_environ;
>  
> -      /* We allocated this space; we can extend it.  */
> +      /* We allocated this space; we can extend it.  Avoid using the raw
> +	 reallocated pointer to avoid GCC -Wuse-after-free.  */
> +      uintptr_t ip_last_environ = (uintptr_t)last_environ;
>        new_environ = (char **) realloc (last_environ,
>  				       (size + 2) * sizeof (char *));
>        if (new_environ == NULL)

Cleaner would be to leave the old code alone, except to add this before 
reallocating:

       bool we_allocated_environ = __environ == last_environ;

 > ...
> -      if (__environ != last_environ)
> +      if ((uintptr_t)__environ != ip_last_environ)

And then change the above line to "if (! we_allocated_environ)".

>  	memcpy ((char *) new_environ, (char *) __environ,
>  		size * sizeof (char *));
>  

  reply	other threads:[~2022-01-16  2:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-16  0:21 Martin Sebor
2022-01-16  2:25 ` Paul Eggert [this message]
2022-01-21 23:14   ` Martin Sebor
2022-01-22  0:42     ` Paul Eggert
2022-01-25  0:42       ` Martin Sebor
2022-01-25  1:08         ` Jeff Law
2022-01-18  9:48 ` Florian Weimer
2022-01-20 21:50   ` Martin Sebor
2022-01-25  0:52 ` [PATCH v2 0/5] " Martin Sebor
2022-01-25  0:57   ` [PATCH v2 1/5] " Martin Sebor
2022-01-25 17:46     ` Carlos O'Donell
2022-01-25  0:58   ` [PATCH v2 2/5] " Martin Sebor
2022-01-25 17:46     ` Carlos O'Donell
2022-01-25  0:58   ` [PATCH v2 3/5] " Martin Sebor
2022-01-25 17:47     ` Carlos O'Donell
2022-01-25  0:58   ` [PATCH v2 4/5] " Martin Sebor
2022-01-25 17:49     ` Carlos O'Donell
2022-01-25 17:51       ` Carlos O'Donell
2022-01-25 21:47         ` Florian Weimer
2022-01-26 13:55           ` Carlos O'Donell
2022-01-25  0:58   ` [PATCH v2 5/5] " Martin Sebor
2022-01-25 17:49     ` Carlos O'Donell
2022-01-25 22:50       ` [PATCH v3 " Martin Sebor
2022-01-26 14:56         ` Carlos O'Donell
2022-01-28 13:10           ` Joseph Myers
2022-01-28 17:33             ` Carlos O'Donell
2022-01-28 17:51               ` Joseph Myers
2022-01-28 23:21                 ` Jeff Law
2022-01-31 15:12                 ` Carlos O'Donell
2022-02-04 20:40                   ` Joseph Myers
2022-01-25 17:46   ` [PATCH v2 0/5] " Carlos O'Donell
2022-01-26  3:08     ` Martin Sebor

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=c5a4ce27-aaec-5bd0-7402-4faaa9460e11@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    --cc=msebor@gmail.com \
    /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).