Re: [PATCH v2] elf: handle addition overflow in _dl_find_object_update_1 [BZ #32245]

[Andreas Schwab <schwab@suse.de>]

On Nov 11 2024, 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.

Ok.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."