1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
commit 8ee69e06336d65b15364f4db82d91775d0fe47c6
Author: Paul Stewart <pstew@google.com>
Date: Sat Oct 9 17:29:51 2010 +0300
dbus_new_handlers: Don't send NULL to dbus_message_new_error
The new DBus API helper function wpas_dbus_error_unknown_error
function can be called as a result of a failure within internal
getter calls, which will call this function with a NULL message
parameter. However, dbus_message_new_error looks very unkindly
(i.e, abort()) on a NULL message, so in this case, we should not
call it.
I've observed this course of events during a call to
wpas_dbus_getter_bss_wpa with a faileld parse of the IE parameter.
We got here through a call to fill_dict_with_properties which
explicitly calls getters with a NULL message parameter. Judging
from the way it is called, this could easily occur if an AP sends
out a malformed (or mis-received) probe response. I usually run
into this problem while driving through San Francisco, so I'm
exposed to any number of base stations along this path.
Index: wpa_supplicant/dbus/dbus_new_handlers.c
===================================================================
--- a/wpa_supplicant/dbus/dbus_new_handlers.c
+++ b/wpa_supplicant/dbus/dbus_new_handlers.c 2011-06-19 22:42:06.912577474 -0300
@@ -117,6 +117,20 @@
DBusMessage * wpas_dbus_error_unknown_error(DBusMessage *message,
const char *arg)
{
+ /*
+ * This function can be called as a result of a failure
+ * within internal getter calls, which will call this function
+ * with a NULL message parameter. However, dbus_message_new_error
+ * looks very unkindly (i.e, abort()) on a NULL message, so
+ * in this case, we should not call it.
+ */
+ if (message == NULL) {
+ wpa_printf(MSG_INFO, "dbus: wpas_dbus_error_unknown_error "
+ "called with NULL message (arg=%s)",
+ arg ? arg : "N/A");
+ return NULL;
+ }
+
return dbus_message_new_error(message, WPAS_DBUS_ERROR_UNKNOWN_ERROR,
arg);
}
|
