bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clang's memory sanitizer triggers in freea()


From: Eric Blake
Subject: Re: clang's memory sanitizer triggers in freea()
Date: Fri, 21 Jul 2017 10:12:38 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 07/21/2017 09:32 AM, Tim Rühsen wrote:
> Hi,

[you signed your mail with an expired gpg key...]

> 
> I am trying to use clang's address sanitizer on libidn2.
> 
> It finds the use of uninitialized stack memory in malloca.c/freea()
> (latest gnulib sources).
> 
> It is this line which causes problems:
> 
>       if (((int *) p)[-1] == MAGIC_NUMBER)
> 
> 
> Is there anything that can/should be done in the code ?

The access really is undefined per C rules, but safe in practice because
of the size of the stack (the access may be out of bounds but is
guaranteed not to fault), and while our decision based on the comparison
can very-occasionally hit a false positive, our slow path code should
correctly handle that.

So the best we can do is annotate the code to state that we are
intentionally stepping outside the bounds of safe C.

> 
> Maybe using clang's __attribute__((no_sanitize("memory"))) (see
> https://clang.llvm.org/docs/MemorySanitizer.html#handling-external-code) ?

If it works.  Patches welcome (I don't use clang enough myself to easily
test the idea).

> 
> Or is it even a false positive that should be addressed at llvm/clang ?

No, this is one case where the compiler IS flagging a real violation of
the C standard (where we are instead relying on our knowledge of how
hardware really behaves to still get reliable behavior).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]