If daemon gets disconnected from D-Bus sender is NULL. Watches that
was explicitly added with NULL sender (ie disconnected_signal in
g_dbus_set_disconnect_function) should be called anyway.
When subscribing to the D-Bus signal NameOwnerChanged from the bus driver,
specify the object path and the sender in the match rule. Otherwise, random
connections on the bus could impersonate the bus driver.
If g_dbus_add_service_watch is called for service which bus name is
already known the following crash can happen:
invalid read of size 1
at 0x4C2A2F2: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E97722: g_strdup (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x405B0C: update_name_cache (watch.c:435)
by 0x405C37: update_service (watch.c:593)
by 0x4E7A2A5: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E7A627: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E7AA39: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4038EA: client_ready (test-gdbus-client.c:1014)
by 0x4E9E5E0: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E9E7A5: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E9EB1A: g_test_run_suite (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x403614: main (test-gdbus-client.c:1058)
Address 0x5dbe5d0 is 0 bytes inside a block of size 7 free'd
at 0x4C28577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E7FF7E: g_free (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x405B04: update_name_cache (watch.c:434)
by 0x405C37: update_service (watch.c:593)
by 0x4E7A2A5: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E7A627: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E7AA39: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4038EA: client_ready (test-gdbus-client.c:1014)
by 0x4E9E5E0: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E9E7A5: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E9EB1A: g_test_run_suite (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x403614: main (test-gdbus-client.c:1058)
When disconnecting from D-Bus a message could be recieved with no sender:
Invalid read of size 1
at 0x4A09EE1: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C386B8: g_str_equal (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4065D6: message_filter (watch.c:529)
by 0x3B0700F9E5: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x4052E7: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4038C5: client_proxy_removed (test-gdbus-client.c:902)
by 0x3B03C6B566: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C6B6E5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
In case of filter_data having a watch to a service name it may call
dbus_connection_remove_filter twice causing libdbus to abort:
process 24723: Attempt to remove filter function 0x4063e0 user data (nil), but no such filter has been added
To fix this the code will now only attempt to call
dbus_connection_remove_filter once in filter_data_free which is the
counterpart of filter_data_get where dbus_connection_add_filter is called.
at 0x40570C: update_service (watch.c:601)
by 0x40584B: service_reply (watch.c:627)
by 0x3B0700C511: ??? (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x3B0700F740: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x405167: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x4c58a30 is 32 bytes inside a block of size 56 free'd
at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C4D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x406102: filter_data_remove_callback (watch.c:378)
by 0x405FC0: g_dbus_remove_watch (watch.c:798)
by 0x40A22B: g_dbus_client_unref (client.c:1227)
by 0x40570B: update_service (watch.c:599)
by 0x40584B: service_reply (watch.c:627)
When we add a signal handler with g_dbus_add_signal_watch(), this
function tries to multiplex the matches added in libdbus by checking
if there's a previous filter_data with the same fields. However, if the
field is NULL it accepts as being the same. The result is that the
following watches will use the same filter data:
watch1 = g_dbus_add_signal_watch(conn, BUS_NAME, NULL, iface, member,
cb1, data1, NULL);
watch2 = g_dbus_add_signal_watch(conn, BUS_NAME, "/path2", iface, member,
cb2, data2, NULL);
watch3 = g_dbus_add_signal_watch(conn, BUS_NAME, "/path3", iface, member,
cb3, data3, NULL);
The result is that when a signal arrives with path == "/path2", all 3
callbacks above will be called, with the same signal delivered to all of
them.
Another problem is that, if we invert the calls like below, only signals
to cb1 will never be trigerred, nonetheless it used path == NULL.
watch2 = g_dbus_add_signal_watch(conn, BUS_NAME, "/path2", iface, member,
cb2, data2, NULL);
watch1 = g_dbus_add_signal_watch(conn, BUS_NAME, NULL, iface, member,
cb1, data1, NULL);
watch3 = g_dbus_add_signal_watch(conn, BUS_NAME, "/path3", iface, member,
cb3, data3, NULL);
This is fixed by not multiplexing the matchs with filter data if any of
the fields are different, including being NULL. When a signal arrives,
if a field is NULL we accept it as a match, but not when adding the
signal handler.
If there's a signal watch that's also watching for name
(data->name_watch) currently we are trying to remove the message_filter
twice since we may have the following call chain:
filter_data_remove_callback()
filter_data_free()
g_dbus_remove_watch()
filter_data_remove_callback()
filter_data_free()
dbus_connection_remove_filter()
dbus_connection_remove_filter()
Because of this we can't currently watch for signals passing the bus
name. After this patch we don't have this issue anymore.
We fix it by removing the filter before calling filter_data_free() if we
are the last filter_data and thus avoid calling
dbus_connection_remove_filter() twice.
Even though service watches accepted a "destroy" callback, they were
being ignored. This fix properly pass them along so they are called when
the watch is removed.
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>
Pending call should be removed if the watch is removed since the
application no longer expect that to be reached and may already freed the
data associated with it.
The bus name should be resolved when adding a watch by service name since
messages do always come with sender set to owner's bus name, also it
should listen to owner updates since it can change without invalidating
the watch.
This was triggering an assert inside libdbus when the timeout inside
the leaking pending call expired. The assert said that we were trying
to remove an nonexistent timeout.
filter_data_find return the first data registered in this case so there is
no guarantee that it return the same data as passed to
filter_data_remove_callback which is the one that should be removed.
The fix is to simple cache the connection removing the correct data before
checking if there is any filter left.
Szymon Janc
Alban Crequy
Luiz Augusto von Dentz
Andrei Emeltchenko
Lucas De Marchi
Anderson Lizardo
Marcel Holtmann
Johan Hedberg
Luiz Augusto von Dentz
Zhenhua Zhang
Vinicius Costa Gomes
Luiz Augusto von Dentz
Marcel Holtmann