[Bug sanitizer/63564] New: -fsanitize=address obscures access to free memory

[Bug sanitizer/63564] New: -fsanitize=address obscures access to free memory

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564

            Bug ID: 63564
           Summary: -fsanitize=address obscures access to free memory
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 33737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33737&action=edit
test example with sem_post to free memory

Hi,

apparently the address sanitizer does not check the sem_post, sem_wait
and similar if the memory is free or the semaphore already deleted.

what makes this worse, is that the attached example crashes
in the following malloc but "works" with -fsanitize=address.

gcc -pthread test.c
./a.out
Segmentation fault (core dumped)

=> app crashes in malloc, not in sem_post!

gcc -pthread -fsanitize=address test.c
./a.out

=> works, and sanitizer "fixes" the malloc!

[Bug sanitizer/63564] -fsanitize=address obscures access to free memory

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
You would need glibc compiled with -fsanitize=address (unless the write is done
in assembly) to detect that.
And, the reason that glibc malloc reports the problem is that it performs some
cheap checks, in particular if you happen to overwrite glibc malloc's internal
data structures, it will sometimes be able to cheaply detect that and report.
asan malloc doesn't have anything like that.
Expecting that -fsanitize=address will reveal all issues in your code is
unrealistic.

[Bug sanitizer/63564] -fsanitize=address obscures access to free memory

[kcc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564

--- Comment #2 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
We don't intercept sem_post/sem_wait and don't instrument glibc where they are
implemented. Sadly, the same applies to quite a few other glibc functions. 
In future we may have fully instrumented glibc,
but in the meantime we need to add more interceptors. 
Patches are welcome, 
see https://code.google.com/p/address-sanitizer/wiki/HowToContribute

Most likely sanitizer_common/sanitizer_common_interceptors.inc  will need to be
modified.

[Bug sanitizer/63564] -fsanitize=address obscures access to free memory

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
In the original example (it was ported from windows,
and the windows semaphores are completely immune
against this kind of error) the sem_post were in
*another* thread and there were several milliseconds
between the free the next malloc. So this is
already a really, really hard to find bug.
But what I don't understand, why the malloc does
*not* crash when address sanitizer is used. 
The same for thread sanitizer, it does not spot
the error, and the error does not happen in debug
builds only in release builds.

[Bug sanitizer/63564] -fsanitize=address obscures access to free memory

[kcc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564

--- Comment #4 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #3)
> In the original example (it was ported from windows,
> and the windows semaphores are completely immune
> against this kind of error) the sem_post were in
> *another* thread and there were several milliseconds
> between the free the next malloc. So this is
> already a really, really hard to find bug.
> But what I don't understand, why the malloc does
> *not* crash when address sanitizer is used. 

If the program has undefined behavior then the program's behavior is, well, 
undefined. You can not expect malloc to crash if there is a bug in the code.
asan's malloc does not rely on malloc headers for bookeeping so it did not
crash.

> The same for thread sanitizer, it does not spot
> the error, and the error does not happen in debug
> builds only in release builds.

Good point. 
tsan does intercept sem_post/sem_wait but does not detect when there is a
use-after-free on it (we do it for pthread_mutex_lock though). 

Dmitry, You may want to add that to tsan.