Summary: | sys-apps/hal-0.5.14: realpath(), fortify and -O2 cause SIGABRT | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Volkov (RETIRED) <pva> |
Component: | Current packages | Assignee: | Daniel Gryniewicz (RETIRED) <dang> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | freedesktop-bugs, Hugo.Mildenberger |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42582 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Peter Volkov (RETIRED)
2010-01-02 19:50:54 UTC
Aha, as gcc devs pointed this is not a bug but feature of glibc. realpath manpage does not mentions this, but reading info libc it's explicitly stated: On systems which define `PATH_MAX' ... the buffer must be large enough for a pathname of this size. Since HAL_PATH_MAX=1024 is smaller then PATH_MAX=4096 this causes this abort. hal should be fixed here. Finally this is fixed upstream: http://cgit.freedesktop.org/hal/commit/?id=a2c3dd5a04d79265772c09c4280606d5c2ed72c6 Please, grab the patch. And yes, it works here. Fixed in 0.5.14-r1. (In reply to comment #4) > Fixed in 0.5.14-r1. This appears to be a semi-valid fix, valid only until a new kernel revision changes PATH_MAX within /usr/include/linux/limits.h Also the dependency on -O appears to be strange behaviour. It stems from __USE_FORTIFY_LEVEL being defined differently on different optimization levels. With -O0 and sys-libs/glibc-2.11-r1, "__USE_FORTIFY_LEVEL > 0" evaluates to false in /usr/include/stdlib.h, 948 #if __USE_FORTIFY_LEVEL > 0 && defined __extern_always_inline 949 # include <bits/stdlib.h> 950 #endif while true with -O1, and this will then result in realpath_chk to be linked in. Here is a test program: #include <stdlib.h> #include <stdio.h> #if __USE_FORTIFY_LEVEL > 0 #warning "__USE_FORTIFIY_LEVEL > 0" #endif int main(int argc, char **argv) { char buffer[512]; printf("__bos(buffer)=%d\n",__bos(buffer)); const char *rp=realpath(argv[0],buffer); return rp!=NULL; } $ gcc -O0 test.c -o test0 $ gcc -O1 test.c -o test1 test.c:5:2: warning: #warning "__USE_FORTIFIY_LEVEL > 0" $ ./test0 __bos(buffer)=512 $ ./test1 __bos(buffer)=512 *** buffer overflow detected ***: test1 - terminated test1: buffer overflow attack in function <unknown> - terminated Report to http://bugs.gentoo.org/ Aborted (core dumped) So, is it correct for -Ox to change __USE_FORTIFY_LEVEL? (In reply to comment #5) > This appears to be a semi-valid fix, valid only until a new kernel revision > changes PATH_MAX within /usr/include/linux/limits.h I had very same idea, but if you want this to change, report at upstream bug, please. > So, is it correct for -Ox to change __USE_FORTIFY_LEVEL? Check info gcc: NOTE: In Gentoo, `-D_FORTIFY_SOURCE=2' is set by default, and is activated when `-O' is set to 2 or higher. This enables additional compile-time and run-time checks for several libc functions. To disable, specify either `-U_FORTIFY_SOURCE' or `-D_FORTIFY_SOURCE=0'. So I guess this is Gentoo specific, is documented and easy to override. This was the fix as applied upstream, so I'm going to leave it this way. I already have to carry enough divergent patches as it is. |