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.
This partially reverts 510b32b7156625b9df737c916b7a7a5c6fb285b9 since it
still necessary to take a reference before calling dbus_watch_handle
since internally it can call watch_info_free as in the following trace:
Invalid read of size 8
at 0x121085: watch_func (mainloop.c:105)
by 0x4C72694: g_main_context_dispatch (gmain.c:2539)
by 0x4C729C7: g_main_context_iterate.isra.23 (gmain.c:3146)
by 0x4C72DC1: g_main_loop_run (gmain.c:3340)
by 0x120541: main (main.c:551)
Address 0x5bbcd90 is 16 bytes inside a block of size 24 free'd
at 0x4A079AE: free (vg_replace_malloc.c:427)
by 0x4C7837E: g_free (gmem.c:252)
by 0x4F708BF: dbus_watch_set_data (dbus-watch.c:614)
by 0x4F70938: _dbus_watch_unref (dbus-watch.c:132)
by 0x4F6E9A7: _dbus_transport_handle_watch (dbus-transport.c:884)
by 0x4F59AFB: _dbus_connection_handle_watch (dbus-connection.c:1497)
by 0x4F70AF9: dbus_watch_handle (dbus-watch.c:683)
by 0x121084: watch_func (mainloop.c:103)
by 0x4C72694: g_main_context_dispatch (gmain.c:2539)
by 0x4C729C7: g_main_context_iterate.isra.23 (gmain.c:3146)
by 0x4C72DC1: g_main_loop_run (gmain.c:3340)
by 0x120541: main (main.c:551)
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)
This actually creates a problem since the code now does flush any pending
message on the queue any signal will be send right away before the
actual reply to GetManagedObjects which will not contain those interfaces.
No matter if disconnection was reported previously, g_dbus_client_unref()
was always calling service disconnect callback. This patch fix the
following scenario:
1) service disconnects from the bus
2) disconnect callback gets called
3) client calls g_dbus_client_unref(), disconnect callback is called
again.
A periodic CLCC polling is started when there is an ongoing multiparty
call and a new call appears in the system. A simple way to reproduce
the crashing scenario is:
1. Place a call.
2. Place a second call.
3. Create a multiparty call with both calls.
4. Place a third call (incoming or outgoing does not matter).
5. Disconnect HFP from the modem.
Within the function ciev_callheld_notify, the AT+CLCC command is also
invoked, thus a new cyclic CLCC polling is started, and it overwrites
the timer resource identifier stored in voicecall_data.clcc_source.
This means that there are several timers doing the CLCC polling, but
only one of those is under control, i.e. it can be removed through its
source identifier, hence a timer source leak.
This has a fatal consequence when the HFP modem is disconnected. The
function hfp_voicecall_remove stops the timer that is under control
before freeing the voicecall_data struct. However there are other timers
that are still active and will execute its handler poll_clcc afterwards.
Inside poll_clcc the driver_data is accessed, which is already NULL.
A solution for this is to avoid starting a CLCC polling if there is
already one active, i.e. clcc_source is not 0. By doing this the
uncontrolled timers will not cycle forever.
Use the authentication method from the mobile-broadband-provider-info
database if it is specified and supported (we support CHAP and PAP).
Default to CHAP if the database does not specify a method (i.e.: the
previous behaviour).
Denis Kenzior
Marcel Holtmann
Alban Crequy
Luiz Augusto von Dentz
Andrei Emeltchenko
Claudio Takahasi
Philip Paeps
Sergio Checa Blanco