This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/21254] Valgrind reports warnings for libc
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 20 Mar 2017 10:05:38 +0000
- Subject: [Bug nptl/21254] Valgrind reports warnings for libc
- Auto-submitted: auto-generated
- References: <bug-21254-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21254
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-03-20
CC| |fweimer at redhat dot com
Component|libc |nptl
Ever confirmed|0 |1
Flags| |security-
--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
Reproducer (more or less):
#include <stdlib.h>
#include <pthread.h>
void *p = &pthread_create;
int main(int argc, char **argv)
{
malloc (10);
return 0;
}
Compile without optimization and link with -static -lpthread.
I think the static TLS allocation is considered uninitialized by valgrind for
some reason. I do not know if valgrind is right here and the memory is
actually uninitialized, or if the kernel guarantees that it is
zero-initialized. Fresh memory returned by brk is generally zero-initialized,
but I don't know what happens if the brk pointer is decremented and incremented
again (say by parasite code in the process—nothing else can run so early during
process setup). Would that cause the kernel to clear the re-exposed memory
region?
--
You are receiving this mail because:
You are on the CC list for the bug.