tag 415573 + moreinfo thanks On Tue, Mar 20, 2007 at 01:33:52PM +0100, Jeroen Massar wrote: > Package: libc6 > Version: 2.3.6.ds1-13 > Severity: important > > > Valgrind has been reporting the following already for a long time: > > ==16241== Thread 2: > ==16241== Conditional jump or move depends on uninitialised value(s) > ==16241== at 0x40270CC: __pthread_manager (manager.c:128) > ==16241== by 0x4151389: clone (clone.S:119) > > This might pose an attack vector, as memory on the stack is not cleared > out per default, depending on the compiler that is used, which in > general is gcc which does not do that; which is evident otherwise > valgrind would not complain about it. > > The problem seems to be somewhere inside: > 8<--------------------------------------------- > /* If we have special thread_self processing, initialize it. */ > #ifdef INIT_THREAD_SELF > INIT_THREAD_SELF(self, 1); > #endif > --------------------------------------------->8 > Which, when trying to follow it, is a huge messy code block. > Trying to determine exactly that this problem occurs is difficult > because of this, it would have been very handy if instead of #defining > functions that code was actually in functions and then let the compiler > choose to optimize it out or not. But that is my opinion. > > Can somebody, more fluent in glibc, take a look at this? Could you please provide a small program (and the flags used to build it) to reproduce the problem ? Does it still apply to glibc2.5 currently in unstable ? -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpEQ7t0CC4X2.pgp
Description: PGP signature