This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
- From: Zack Weinberg <zackw at panix dot com>
- To: Maxim Ostapenko <m dot ostapenko at samsung dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>, Kostya Serebryany <kcc at google dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Wed, 5 Oct 2016 12:06:21 -0400
- Subject: Re: [PATCH BZ#20422] Do not allow asan/msan/tsan and fortify at the same time.
- Authentication-results: sourceware.org; auth=none
- References: <57CDAB08.8060601@samsung.com>
On Mon, Sep 5, 2016 at 1:27 PM, Maxim Ostapenko <m.ostapenko@samsung.com> wrote:
> When fortify is used with MSan it will cause MSan false positives.
I feel like this discussion has gone way into the weeds. Your
original problem report ...
> #include <stdio.h>
> #include <string.h>
> int main()
> {
> char text[100];
> sprintf(text, "hello");
> printf("%lu\n", strlen(text));
> }
>
> % clang test.c -fsanitize=memory -O3 && ./a.out
> 5
> % clang test.c -fsanitize=memory -D_FORTIFY_SOURCE=2 -O3 && ./a.out
> Uninitialized bytes in __interceptor_strlen at offset 0 inside
> [0x7ffe259e4d20, 6)
> ==26297==WARNING: MemorySanitizer: use-of-uninitialized-value
> #0 0x4869cc in main
... appears to me to be a plain old bug. Either the fortify shims are
actually using an uninitialized value, in which case they should be
fixed, or MSan has misunderstood the code generated in _FORTIFY_SOURCE
mode, in which case MSan should be fixed.
You understand what is going on better than anyone else here, I think
- can you please write up a detailed description of exactly why this
goes wrong?
zw