|
From: Christian P. <tr...@ge...> - 2006-12-26 11:11:26
|
Hi all... I do not know what else to do to get rid of this warning: =3D=3D16105=3D=3D Thread 2: =3D=3D16105=3D=3D Syscall param timer_create(evp) points to uninitialised b= yte(s) =3D=3D16105=3D=3D at 0x80A7F7F: timer_create (in /lib64/librt-2.5.so) =3D=3D16105=3D=3D by 0x737B267: System::Realtime::TTimerBase::start()=20 (TTimer.unix.cpp:87) [....] even when memset()'ing evp to sizeof(epv) to 0 I won't get rid of it. I tested it also a glibc's tst-timer.c (provided by their upstream distfile= )=20 which leads into the same result. Regards, Christian Parpart. |
|
From: Bart V. A. <bar...@gm...> - 2006-12-26 12:17:05
|
On 12/26/06, Christian Parpart <tr...@ge...> wrote: > > Hi all... > > I do not know what else to do to get rid of this warning: > > ==16105== Thread 2: > ==16105== Syscall param timer_create(evp) points to uninitialised byte(s) > ==16105== at 0x80A7F7F: timer_create (in /lib64/librt-2.5.so) > ==16105== by 0x737B267: System::Realtime::TTimerBase::start() > (TTimer.unix.cpp:87) > [....] > > even when memset()'ing evp to sizeof(epv) to 0 I won't get rid of it. > I tested it also a glibc's tst-timer.c (provided by their upstream > distfile) > which leads into the same result. > > Regards, > Christian Parpart. > My opinion is that this is a glibc bug, and that Valgrind should suppress the above message. See also http://bugs.kde.org/show_bug.cgi?id=124478. Bart. |
|
From: John R.
|
> ==16105== Thread 2: > ==16105== Syscall param timer_create(evp) points to uninitialised byte(s) > ==16105== at 0x80A7F7F: timer_create (in /lib64/librt-2.5.so) > ==16105== by 0x737B267: System::Realtime::TTimerBase::start() > (TTimer.unix.cpp:87) > [....] > > even when memset()'ing evp to sizeof(epv) to 0 I won't get rid of it. > I tested it also a glibc's tst-timer.c (provided by their upstream distfile) > which leads into the same result. The implementation inside glibc copies your argument to a local structure, then passes the address of the local structure to the kernel. The copying does not completely initialize the local structure. The glibc developers do not consider this to be a bug [as of 2004-11-30]: http://bugzilla.redhat.com/beta/show_bug.cgi?id=141137 However, the behavior of passing "uninitialized" bytes (particularly from the stack) into the kernel definitely is an information security leak, and an unnecessary invitation for non-reproducibility bugs. For a patch which fixes this and numerous similar situations in glibc: http://bitwagon.com/glibc-audit/glibc-audit.html -- |
|
From: Bart V. A. <bar...@gm...> - 2006-12-28 12:23:09
|
On 12/27/06, John Reiser <jr...@bi...> wrote: > > > ==16105== Thread 2: > > ==16105== Syscall param timer_create(evp) points to uninitialised > byte(s) > > ==16105== at 0x80A7F7F: timer_create (in /lib64/librt-2.5.so) > > ==16105== by 0x737B267: System::Realtime::TTimerBase::start() > > (TTimer.unix.cpp:87) > > [....] > > > > even when memset()'ing evp to sizeof(epv) to 0 I won't get rid of it. > > I tested it also a glibc's tst-timer.c (provided by their upstream > distfile) > > which leads into the same result. > > The implementation inside glibc copies your argument to a local structure, > then passes the address of the local structure to the kernel. The copying > does not completely initialize the local structure. The glibc developers > do not consider this to be a bug [as of 2004-11-30]: > http://bugzilla.redhat.com/beta/show_bug.cgi?id=141137 > I have filed a glibc bug report for a similar issue with getifaddr() -- I'm curious to see how the glibc maintainers will respond to this ( http://sourceware.org/bugzilla/show_bug.cgi?id=3793). Bart. |
|
From: John R.
|
Bart Van Assche wrote: > I have filed a glibc bug report for a similar issue with getifaddr() -- I'm > curious to see how the glibc maintainers will respond to this ( > http://sourceware.org/bugzilla/show_bug.cgi?id=3793). The patches linked from http://bitwagon.com/glibc-audit/glibc-audit.html handle this case and 73 others where glibc-2.4-4 uses what it considers to be "don't care" uninitialized storage. These cases were found by using another tool, but apply to memcheck. getifaddrs() was patched 2003-04-16, more than three years ago in a prior version of glibc. If your own code is good enough so that glibc is the leading suspect for the remaining complaints from memcheck, then using glibc-audit might enable you to move sooner to more productive work. -- |