[Pkg-utopia-maintainers] Bug#471565: dbus-daemon segfaults

[Brad Jorsch]

I am also seeing this bug, with the log message 
 dbus-daemon[2709]: segfault at 100 ip 00007f0aca0 8c411 sp 00007fffbeec66a0 error 4 in libc-2.10.2.so[7f0aca047000+14a000]

On my system, it is 100% reproducable:
 1. (Re-)Start the system dbus-daemon
 2. (Re-)Start the bluez bluetoothd (/etc/init.d/bluetooth restart)
 3. Start blueman-applet
 4. Use blueman-applet to turn bluetooth on
 5. Issue "hciconfig hci0 reset" (this seems to be an unrelated issue
    with kernel 2.6.33)
 6. Use blueman-applet to turn bluetooth off. Dbus crashes here.

The underlying cause is that passing a struct DBusString by value into
an ellipsis and then reading it back as a char * does not work as
"expected" here; dbus-daemon does this at line 1199 of bus/bus.c by
passing a struct DBusString for a "%s" format string.

It seems that dbus is invoking undefined behavior here. According to the
C standard[1] section 7.15.1.1, which defines the behavior of the va_arg
macro:
> if type is not compatible with the type of the actual next argument
> (as promoted according to the default argument promotions), the
> behavior is undefined, except for the following cases:
>  -- one type is a signed integer type, the other type is the
>     corresponding unsigned integer type, and the value is
>     representable in both types;
>  -- one type is pointer to void and the other is a pointer to a
>     character type.

I don't think a struct passed by value (specifically, DBusString) is "a
pointer to a character type", which is the only way that could be
defined behavior. I note that gcc refuses to compile even an explicit
cast from a struct to a void * or char *. I guess this works when the
struct-passed-by-value just happens to put the first member in the place
where va_arg looks, and nothing tries to use parameters passed into the
ellipsis after the struct.

If I'm right about all that, the simple solution would be to provide an
accessor function or macro that would explicitly pull out that first
member when a char * is needed.

It's also certainly possible that the original reporter (using an x86
system) had a different issue from those of us on amd64. I note all
three of us report the log message with error 4 in
libc-2.10.2.so[...+14a000].


In case it helps, here are the versions of the relevant software on my
system:
 Debian Release: squeeze/sid
 Architecture: amd64 (x86_64)
 Hardware info: http://wiki.debian.org/InstallingDebianOn/Thinkpad/T500
 Kernel: Linux 2.6.33.1 (x86_64 SMP w/2 CPU cores), compiled from
         kernel.org sources using kernel-package
 dbus: 1.2.22-1
 libc6: 2.10.2-6
 gcc-4.4: 4.4.3-3
 blueman: 1.21-3
 bluez: 4.60-1


[1] Or at least the draft version at
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf