Hello again, It seems Cairo (1.0.2) has got something against ProPolice when built this way on AMD64... Whenever I try to run an application depending on it (like every GTK2 app), it dies immediately with the following error message: APPNAME: stack smashing attack in function _cairo_stroker_join() Aborted I suppose that, in addition to having this CFLAG filtered in the ebuild, it might be useful to have the problem reported upstream; unfortunately I cannot verify at the moment whether the same behaviour occurs on x86 and I expect this information would be important for them.
I've found a moment to run some more tests and when using Cairo compiled with - fstack-protector on a 32-bit systems, or at least in 32-bit chroot on a 64-bit system, gets used by the same applications which gave me problems in 64-bit mode (I've tested Sylpheed, The GIMP and mtr). I guess that means the problem is amd64-specific.
It's more likely to be 64bit specific vs amd64. Somebody with 64bit porting expreience should look at the function in question. It's probably using an int when it needs a long in an array or the likes.
I got down to analysing the problem and it turned out the offender is line 317 of cairo-path-stroke.c, "_cairo_polygon_init (&polygon);". However, looking further inside that function I was surprised to see that the exact assignment which overwrites the guard value is this one (cairo-polygon.c:53): polygon->has_current_point = 0; Yes, a perfectly straightforward "let an int equal zero". To make things even weirder, gdb shows that _cairo_polygon_init() gets called several times before this one, without giving any problems whatsoever. Feeling completely confused, I did a thing which came to my mind even though I could see no reason why this would help: in cairo-path-stroke.c, I moved "cairo_polygon_t polygon;" from line 274 (within the block which uses it) to line 183 (beginning of the whole function). ...what do you know, it helped. Apparently the problem is not with optimisation flags I pass to gcc, as even when I reduce my CFLAGS to simple "-fstack-protector" it does not go away. A bug in ProPolice, maybe? In gcc? Anyway, if anyone has any ideas who this should be reported to upstream, let me know.
I was having the exact same issue on hardened amd64, and applying the changes the original reporter posted above seems to have solved the problem here, too. (btw: Marek Szuba; thanks, this was driving me nuts)
An extra datapoint, if of any use: I had the same problem with gaim and firefox on amd64, and it went away when compiling cairo with vanilla gcc, as these people suggested: http://forums.gentoo.org/viewtopic-t-419581-highlight-stack+smashing+attack+cairostrokerjoin.html http://forums.gentoo.org/viewtopic-t-419914-highlight-cairo+hardened.html So this might be an issue with hardened gcc. It does *not* seem to be an issue with hardened cairo: recompiling cairo (and/or gaim, for that matter) with USE="-hardened" did not fix the problem when cairo was compiled with hardened gcc. HTH.
*** Bug 118432 has been marked as a duplicate of this bug. ***
Created attachment 78248 [details, diff] cairo 1.0.2 hardened amd64 patch I just ran into the exact same problem again on a new install. Here's a patch against cairo 1.0.2 which simply implements the fix Marek Szuba outlined above.
I had the same problem on amd64 hardened. I confirm that this patch is working for me.
*** Bug 122360 has been marked as a duplicate of this bug. ***
*** Bug 123064 has been marked as a duplicate of this bug. ***
This is also reported on freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=5026 I'll try the patch in a bit. :)
... and the patch works. Yay. :)
Can this patch be merged into portage?
The problem persists with cairo-1.0.4 and gcc-3.4.6.
foser created this ebuild not I. The solution is merged locally in my 1.0.4 ebuild. I informed foser of the situation but he didn't care to fix it.
(In reply to comment #15) > foser created this ebuild not I. > Lets reassign this bug to foser then. :)
Created attachment 84172 [details] Ebuild with patch For those of you who don't know how to apply the patch of Hopeless, here is a new ebuild which applies his patch. Activate your portage overlay if not already done. Change directory to your portage overlay (eg cd /usr/local/portage) and tar -xvf x11-lib-cairo-1.0.2-r1.tgz emerge -pv cairo emerge =cairo-1.0.2-r1 I hope I don't break portage naming conventions.
Compiling cairo with "USE=-hardened", as well as other usual workarounds as recompiling it the vanilla gcc or using the -nostack-protector-all flag. The only thing, I've found that solves this problem is applying the patched version suggested in this thread. Although this should be evaluated before applying it to the official portage tree, it seems to work as expected.
The patch works with 1.0.4 as well. And for those who wish to to modify their local ebuild to patch their source: nayru cairo # diff -u /usr/portage/x11-libs/cairo/cairo-1.0.4.ebuild /usr/local/portage/x11-libs/cairo/cairo-1.0.4.ebuild --- /usr/portage/x11-libs/cairo/cairo-1.0.4.ebuild 2006-04-15 21:07:09.000000000 +0200 +++ /usr/local/portage/x11-libs/cairo/cairo-1.0.4.ebuild 2006-04-19 12:07:12.000000000 +0200 @@ -29,6 +29,14 @@ doc? ( >=dev-util/gtk-doc-1.3 ~app-text/docbook-xml-dtd-4.2 )" +src_unpack() { + unpack "${A}" + cd "${S}" + + # Call PKG_PROG_PKG_CONFIG to fix other standard pkg-config calls + epatch ${FILESDIR}/cairo-1.0.2-amd64_hardened.patch +} + src_compile() { econf $(use_enable X xlib) \
The patch also works with 1.1.6 (the ebuild for which is currently masked, though). And for those who wish to to modify their local ebuild to patch their source: nayru cairo # diff -u /usr/portage/x11-libs/cairo/cairo-1.1.6.ebuild cairo-1.1.6.ebuild --- /usr/portage/x11-libs/cairo/cairo-1.1.6.ebuild 2006-05-20 22:37:29.000000000 +0200 +++ cairo-1.1.6.ebuild 2006-05-25 15:01:45.000000000 +0200 @@ -37,6 +37,9 @@ # No non-cvs version of poppler has poppler_page_render epatch "${FILESDIR}"/${P}-poppler-revert.patch + # Call PKG_PROG_PKG_CONFIG to fix other standard pkg-config calls + epatch ${FILESDIR}/cairo-1.0.2-amd64_hardened.patch + eautoreconf }
Confirming. Patch solves this problem for version 1.0.4
I would like to question this patch to the source. Moving the variable definition to the top of the function does not seem to directly fix the problem. I'd like to get another person's opinion on this. If we can confirm that this is the right solution, I will commit the ebuild changes.
I confirm this patch for v1.0.2 and 1.0.4. Moving the variable declaration directly solves the bug, even though I have no idea why (excecpt a bug in gcc?)
the patch is kind of nonsense because it does only shift a variable declaration to a different place within the same function, but hey, it can't harm anything that way either, so it's in now (1.0.4-r1). Thanks Hopeless!
For anybody that thinks this bug is nonsense please look at the asm output to see why/how it's really working around the bug in gcc.
