[PATCH v1] x86: memcmp-avx2-movbe.S and memcmp-evex-movbe.S fix overflow bug.

Siddhesh Poyarekar siddhesh@gotplt.org
Wed Jun 9 05:25:48 GMT 2021


On 6/9/21 10:45 AM, Noah Goldstein wrote:
> 
> 
> On Mon, Jun 7, 2021 at 1:45 PM Paul Eggert <eggert@cs.ucla.edu 
> <mailto:eggert@cs.ucla.edu>> wrote:
> 
>     On 6/7/21 10:28 AM, Noah Goldstein via Libc-alpha wrote:
>      >
>      > Is it actually UB? The caller is not causing overflow. The
>     implementation
>      > method is. It is possible to implement without overflow.
> 
>     The C Standard says that unless otherwise specified, when you pass an
>     array (pointer + size) to a standard function, all the addresses in the
>     array must be valid. It's valid if (say) memcmp is multithreaded and
>     compares the first halves of the two arrays in parallel with comparing
>     the second halves.
> 
> 
> Does this mean there is an issue with functions like wcsnlen?
> 
> They do say that they only need to be able to access memory up
> to first null terminator but currently the x86_64 wcsnlen-avx2.S
> implementation will multiple length by 4 which could cause overflow.
> 
> For example with a string length 1000 and maxlen passed as
> 2^62 + 1 the return will be 1.

The maxlen causes undefined behaviour; it is the responsibility of the 
caller to ensure that it doesn't and the way to do that for wcsnlen is 
to ensure that s+maxlen*sizeof(wchar_t) is within bounds of the object 
and hence does not cause overflow.
Siddhesh


More information about the Libc-alpha mailing list