Package: gcc-4.6 Version: 4.6.3-1 Justification: causes non-serious data loss Severity: grave
When compiling GNUnet on our sparc buildbot, gcc decides to place the "hc" variable from file https://gnunet.org/doxygen/d7/dc5/gnunet-service-mesh_8c_source.html in line 3860 at an inadequate stack offset; the type of the variable is this https://gnunet.org/doxygen/d6/d36/struct_g_n_u_n_e_t___hash_code.html which should be placed on a 4-byte boundary (as confirmed by an extensive discussion with Eric Botcazou; who could not say if this was a Debian or an upstream issue). Note that swapping the 'hc' with 'u16' does not solve the problem; however adding an 'align(4)' attribute does fix the issue. The result of the mis-alignment is that a few lines later a pointer to the variable on the stack is dereferenced, resulting in a SIGBUS. This is a security issue, as now virtually any complex C code compiled with this version of gcc can theoretically result in a SIGBUS at any time. I've tried to produce a simpler instance of the bug (mimicking a similar stack layout) but failed to get gcc to create the bad stack layout with "simpler" code. The problem also exists with gcc 4.4 (where we observed it first, but then updated to 4.6 to see if it disappeared). I believe this is a security issue (in the broadest sense) as with this bug virtually *any* non-trivial C code compiled with gcc could SIGBUS at any time, resulting in data-loss for the current process. Given that the issue is hard to reproduce, I'm happy to say that we can easily give shell access to our system; alternatively, the best procedure to reproduce is to: 1) download and install GNUnet from SVN HEAD (difficult on Debian due to outdated dependencies, but possible, see http://gnunet.org/) 2) enable core dumps (ulimit -c 9999999, etc.) 3) run 'make check' in src/vpn/ (after running 'make install' as root) 4) enjoy the core dumps with gdb (they are usually a bit useless, but show the sigbus) -- now you know the system is affected 5) run "gnunet-arm -s" with a default configuration with all applications (fs, vpn) disabled and 'AUTOSTART=NO' for mesh; 6) run 'gdb gnunet-service-mesh' 7) run 'gnunet-arm -i exit' in another shell 8) observe gdb-supervised gnunet-service-mesh crashing, now with nice stack trace for the SIGBUS; enjoy the stack layout Again, while running into this bad stack layout seems to not happen easily, non-deterministic crashes are still data-loss issues (so re-compiling *all* of Debian/Sparc might be indicated after fixing this issue...). Happy hacking! Christian -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (700, 'stable'), (650, 'testing') Architecture: sparc (sparc64) Kernel: Linux 2.6.32-5-sparc64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.6 depends on: ii binutils 2.22-6 GNU assembler, linker and binary u ii cpp-4.6 4.6.3-1 GNU C preprocessor ii gcc-4.6-base 4.6.3-1 GCC, the GNU Compiler Collection ( ii libc6 2.13-27 Embedded GNU C Library: Shared lib ii libgcc1 1:4.7.0-3 GCC support library ii libgmp10 2:5.0.4+dfsg-1 Multiprecision arithmetic library ii libgomp1 4.7.0-3 GCC OpenMP (GOMP) support library ii libmpc2 0.9-4 multiple precision complex floatin ii libmpfr4 3.1.0-4 multiple precision floating-point ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gcc-4.6 recommends: ii libc6-dev 2.13-27 Embedded GNU C Library: Developmen Versions of packages gcc-4.6 suggests: pn binutils-gold <none> (no description available) pn gcc-4.6-doc <none> (no description available) pn gcc-4.6-locales <none> (no description available) pn gcc-4.6-multilib <none> (no description available) pn libgcc1-dbg <none> (no description available) pn libgomp1-dbg <none> (no description available) pn libmudflap0-4.6-dev <none> (no description available) pn libmudflap0-dbg <none> (no description available) pn libquadmath-dbg <none> (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f99b7a7.9020...@grothoff.org
