|
From: <sv...@va...> - 2006-04-12 13:42:09
|
Author: sewardj
Date: 2006-04-12 14:41:51 +0100 (Wed, 12 Apr 2006)
New Revision: 5844
Log:
Add a suppression for yet another glibc string function: __strcpy_chk.
We really ought intercept/replace this, and that would be easy, except
__strcpy_chk uses __chk_fail and I haven't figured out what that
is/does.
Modified:
trunk/glibc-2.4.supp
Modified: trunk/glibc-2.4.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/glibc-2.4.supp 2006-04-12 11:42:54 UTC (rev 5843)
+++ trunk/glibc-2.4.supp 2006-04-12 13:41:51 UTC (rev 5844)
@@ -61,6 +61,14 @@
obj:/lib*/libc-2.3.90.so
}
=20
+{
+ Fedora-Core-5-__strcpy_chk-64bit-hack-TODO-fix-this-properly
+ Memcheck:Addr8
+ fun:__strcpy_chk
+ obj:/usr/lib64/libX11.so.6.2.0
+ obj:/usr/lib64/libX11.so.6.2.0
+}
+
##----------------------------------------------------------------------=
##
{
glibc-2.3.x-on-SUSE-10.1-(PPC)-1
|
|
From: Tom H. <to...@co...> - 2006-04-12 14:03:35
|
In message <200...@ja...>
sv...@va... wrote:
> Add a suppression for yet another glibc string function: __strcpy_chk.
> We really ought intercept/replace this, and that would be easy, except
> __strcpy_chk uses __chk_fail and I haven't figured out what that
> is/does.
__strcpy_chk is a checked version of strcpy - it takes an extra
argument which is the length of the target buffer and if that would
be overflowed it calls __chk_fail to abort the program I believe.
The __strcpy_chk calls are generated automagically by gcc if you
compile with some special option when you call strcpy and gcc can
work out the size of the target buffer (because it is a local on
the stack or something).
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-04-12 14:11:41
|
> __strcpy_chk is a checked version of strcpy - it takes an extra
> argument which is the length of the target buffer and if that would
> be overflowed it calls __chk_fail to abort the program I believe.
Yes. We could easily enough redirect it to a copy of the function
in glibc's sysdeps/generic/strcpy_chk.c (and that would be a
preferable solution). It's just that I couldn't figure out what
__chk_fail() should be.
debug/chk_fail.c has this:
void
__attribute__ ((noreturn))
__chk_fail (void)
{
/* The loop is added only to keep gcc happy. */
while (1)
__libc_message (1, "*** buffer overflow detected ***: %s terminated\n",
__libc_argv[0] ?: "<unknown>");
}
I wasn't clear if this is a special version for debugging, or is this
definition always used? If yes, then does __libc_message abort the
program?
> The __strcpy_chk calls are generated automagically by gcc if you
> compile with some special option when you call strcpy and gcc can
> work out the size of the target buffer (because it is a local on
> the stack or something).
Ah, ok. I'd never come across it before today.
I see you've switched one of your nightly build machines to FC5-amd64,
which is good.
J
|
|
From: Tom H. <to...@co...> - 2006-04-12 14:21:29
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> I wasn't clear if this is a special version for debugging, or is this
> definition always used? If yes, then does __libc_message abort the
> program?
If the first argument (do_abort) is non-zero then yes it does. You
can find __libc_message in sysdeps/unix/sysv/linux/libc_fatal.c in
the glibc source.
> I see you've switched one of your nightly build machines to FC5-amd64,
> which is good.
Yep. I upgraded my workstation at work to FC5 which gave that - my
home machine has also gone to FC5 which gives us a 32 bit build. I
managed to find other FC4 boxes so we still have 32 and 64 bit builds
of that as well.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|