Bug#670578: gcc-4.6: [sparc] compiler fails to align stack-allocated struct,with array of uint32-values to 32-bit boundary
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
Reply to: