public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: John David Anglin <dave.anglin@bell.net>
To: Aurelien Jarno <aurelien@aurel32.net>, libc-alpha@sourceware.org
Cc: John David Anglin <danglin@gcc.gnu.org>, Andreas Schwab <schwab@suse.de>
Subject: Re: [PATCH v2] elf: handle addition overflow in _dl_find_object_update_1 [BZ #32245]
Date: Mon, 11 Nov 2024 18:05:02 -0500	[thread overview]
Message-ID: <f7964f4b-a73d-40a0-8781-faa23849660c@bell.net> (raw)
In-Reply-To: <20241111224832.911593-1-aurelien@aurel32.net>

On 2024-11-11 5:48 p.m., Aurelien Jarno wrote:
> The remaining_to_add variable can be 0 if (current_used + count) wraps,
> This is caught by GCC 14+ on hppa, which determines from there that
> target_seg could be be NULL when remaining_to_add is zero, which in
> turns causes a -Wstringop-overflow warning:
>
>   In file included from ../include/atomic.h:49,
>                    from dl-find_object.c:20:
>   In function '_dlfo_update_init_seg',
>       inlined from '_dl_find_object_update_1' at dl-find_object.c:689:30,
>       inlined from '_dl_find_object_update' at dl-find_object.c:805:13:
>   ../sysdeps/unix/sysv/linux/hppa/atomic-machine.h:44:4: error: '__atomic_store_4' writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
>      44 |    __atomic_store_n ((mem), (val), __ATOMIC_RELAXED);                        \
>         |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   dl-find_object.c:644:3: note: in expansion of macro 'atomic_store_relaxed'
>     644 |   atomic_store_relaxed (&seg->size, new_seg_size);
>         |   ^~~~~~~~~~~~~~~~~~~~
>   In function '_dl_find_object_update':
>   cc1: note: destination object is likely at address zero
>
> In practice, this is not possible as it represent counts of link maps.
> Link maps have sizes larger than 1 byte, so the sum of any two link map
> counts will always fit within a size_t without wrapping around.
>
> This patch therefore adds a check on remaining_to_add == 0 and tell GCC
> that this can not happen using __builtin_unreachable.
>
> Thanks to Andreas Schwab for the investigation.
>
> Closes: BZ #32245
> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Except for comment,
tested-by: John David Anglin <dave.anglin@bell.net>
> ---
>   elf/dl-find_object.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c
> index 449302eda3..ae18b438d3 100644
> --- a/elf/dl-find_object.c
> +++ b/elf/dl-find_object.c
> @@ -662,6 +662,14 @@ _dl_find_object_update_1 (struct link_map **loaded, size_t count)
>       = _dlfo_loaded_mappings[!active_idx];
>     size_t remaining_to_add = current_used + count;
>   
> +  /* remaining_to_add can be 0 if (current_used + count) wraps, but in practice
> +     this is not possible as it represent counts of link maps.  Link maps have
> +     sizes larger than 1 byte, so the sum of any two link map counts will
> +     always fit within a size_t without wrapping around.  This check ensures
> +     that target_seg is not erroneously considered potentially NULL by GCC. */
> +  if (remaining_to_add == 0)
> +    __builtin_unreachable ();
> +
>     /* Ensure that the new segment chain has enough space.  */
>     {
>       size_t new_allocated


-- 
John David Anglin  dave.anglin@bell.net


  reply	other threads:[~2024-11-11 23:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-11 22:48 Aurelien Jarno
2024-11-11 23:05 ` John David Anglin [this message]
2024-11-12 10:36 ` Andreas Schwab
2024-11-12 11:45 ` Florian Weimer
2024-11-21 16:54 ` Joseph Myers

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=f7964f4b-a73d-40a0-8781-faa23849660c@bell.net \
    --to=dave.anglin@bell.net \
    --cc=aurelien@aurel32.net \
    --cc=danglin@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=schwab@suse.de \
    /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).