GNOME Bugzilla – Bug 459323
Crash when calling getAddress on a Network object with dbus-send
Last modified: 2008-08-16 03:56:57 UTC
I've been exploring talking to NetworkManager, and have found a crash with NetworkManager 0.6.4 from Ubuntu Feisty Fawn. All I need to to do to crash NetworkManager is run this command: dbus-send --system --print-reply --type=method_call \ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager/Devices/eth1/Networks/eliza1 \ org.freedesktop.NetworkManager.Devices.getAddress where ".../eth1" is the wireless device in my laptop and ".../eliza1" is the wireless network I'm connected to. The network is encrypted with WEP. NetworkManagerDispatcher remains running after this. Other calls with this same command (for example "...getName") behave as expected.
Any chance you could install debuginfo/symbols for NetworkManager, gdb attach to it before calling this function, and provide a backtrace?
(In reply to comment #1) > Any chance you could install debuginfo/symbols for NetworkManager, gdb attach > to it before calling this function, and provide a backtrace? Sure. I've since upgraded to Gutsy Gibbon, which comes with NetworkManager 0.6.5, but I can still trigger the bug. I've got some debugging symbols installed for glib and rebuild network-manager with debugging symbols. Here's the results of "thread apply all backtrace" after triggering the crash: (gdb) thread apply all bt
+ Trace 181970
(In reply to comment #1) > Any chance you could install debuginfo/symbols for NetworkManager, gdb attach > to it before calling this function, and provide a backtrace? One more note - I saw some bugs reported with 128-bit WEP networks in bugzilla, so I just reproduced this with an open wireless AP and see the same backtrace.
Does this happen with 0.6.6 or higher? the backtrace doesn't seem to show the crash, does gdb interrupt the program with a segfault warning?
Yep, I still see this crash with 0.6.6 from Hardy Heron. Here is a new thread apply all bt: (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7b9f720 (LWP 5373)] 0xb7ce6283 in strlen () from /lib/tls/i686/cmov/libc.so.6 (gdb) thread apply all bt
+ Trace 197461
Thread 1 (Thread 0xb7b9f720 (LWP 5373))
I'm going to poke around on this crash a bit more and may try current development head.
Created attachment 110730 [details] [review] Allocate buf from the heap since Dbus needs to access it while marshalling a string
I have found the problem. In nm-dbus-net.c:nm_dbus_net_get_address(), NM does the following sequence: char buf[20]; ... dbus_message_append_args (reply, DBUS_TYPE_STRING, &buf, DBUS_TYPE_INVALID); Following dbus_message_append_args() down the call stack is _dbus_marshal_write_basic, which assumes that the pointer it was passed is on the heap: dbus_bool_t _dbus_marshal_write_basic (DBusString *str, int insert_at, int type, const void *value, int byte_order, int *pos_after) { const DBusBasicValue *vp; ... vp = value; During the marshal of the string, dbus does strlen(vp->str) -> SEGV, since vp points to a variable on the stack opf nm_dbus_net_get_address(). The attached patch fixes this crash for me, but this seems like the kind of thing that could be in other places as well. Should dbus really dereference values passed to it for message encapsulation?
thanks, fixed in svn r3972