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.
This commit is contained in:
Paul Stewart 2010-10-09 17:29:51 +03:00 committed by Jouni Malinen
parent 556522ee09
commit 8ee69e0633

View file

@ -117,6 +117,20 @@ static char * wpas_dbus_new_decompose_object_path(const char *path,
DBusMessage * wpas_dbus_error_unknown_error(DBusMessage *message, DBusMessage * wpas_dbus_error_unknown_error(DBusMessage *message,
const char *arg) 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, return dbus_message_new_error(message, WPAS_DBUS_ERROR_UNKNOWN_ERROR,
arg); arg);
} }