Allows informing the connection manager of additional information on CQM
events. Allows the connection manager to request the same information
on demand by using the existing "SignalPoll" method.
* Add new property "SignalChange"
* Add storage for wpa_signal_info into wpa_supplicant context
object
* Copy memory from event to context object on CQM Event
* Write a common conversion method to be used by both "SignalPoll" and
this property
Signed-off-by: David Ruth <druth@chromium.org>
entry->strarray_value was left to point to freed memory in case
os_realloc_array() failed. This resulted in the following
wpa_dbus_dict_entry_clear() trying to free an already freed memory area.
In addition, the separately allocated strings in the array would have
been leaked in such a case. Furthermore, wpa_dbus_dict_entry_clear() was
not prepared for the possibility of the initial os_calloc() call failing
and entry->strarray_value being NULL without array_len being cleared to
zero. That would have resulted in reading uninitialized memory and NULL
pointer dereference.
Signed-off-by: Jouni Malinen <j@w1.fi>
entry->bytearray_value was left to point to freed memory in case
os_realloc_array() failed. This resulted in the following
wpa_dbus_dict_entry_clear() trying to free an already freed memory area.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to have multiple separate return statements for error
cases in a sequence of operations. In addition, there is not much point
in "converting" boolean return values with "if (!res) return FALSE;
return TRUE;" style constructions.
Signed-off-by: Jouni Malinen <j@w1.fi>
It looks like both gcc and clang optimize the (entry.type != foo ||
entry.array_type != bar) in a way that ends up evaluating the second
condition even when the first one results in 0. While this is not really
what the C language requirements on short-circuit evaluation require,
the compiler likely assumes this can have no side effects and with both
type and array_type being comparable in a single 64-bit operation, this
can clearly be a bit more efficient. While the code behaves same in both
cases, valgrind does warn about use of uninitialized memory when the
second condition is evaluated (entry.array_type is not initialized if
entry.type != DBUS_TYPE_ARRAY).
To keep valgrind logs cleaner, initialize entry.array_type to
DBUS_TYPE_INVALID so that these compiler optimizations do not result in
reading uninitialized memory.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed to allow Set(P2PDeviceConfig) to clear the
VendorExtension array (i.e., to remove all configured vendor
extensions). Previously, such an attempt was met with a D-Bus assert and
rejection of the operation.
Signed-off-by: Jouni Malinen <j@w1.fi>
There were couple of missing breaks in switch-default (before/after).
While these did not have any noticeable issues due to falling over to
the next step that just exited from the switch statement, it is cleaner
and more robust to have each case use an explicit break.
Signed-off-by: Jouni Malinen <j@w1.fi>
The tmpentry variable was not initialized and
_wpa_dbus_dict_entry_get_byte_array() does not set tmpentry.type, so it
would have been possible for the error path to end up trying to free
unexpected type of an entry or not free the memory at all.
Signed-off-by: Jouni Malinen <j@w1.fi>
This updates these files to use the license notification that uses only
the BSD license. The changes were acknowledged by email (Dan Williams
<dcbw@redhat.com>, Sun, 01 Jul 2012 15:53:36 -0500).
Signed-hostap: Jouni Malinen <j@w1.fi>
Some of the standard lib functions being used directly are redefined in
src/utils/os.h thus providing an abstraction. Change code to use os_*
functions instead of directly using the lib functions.
Signed-hostap: Nirav Shah <nirav.j2.shah@intel.com>
Signed-hostap: Angie Chinchilla <angie.v.chinchilla@intel.com>
When parsing a dict entry which is an array of an array of bytes the entry
representing the dict entry has DBUS_TYPE_ARRAY as its type and
WPAS_DBUS_TYPE_ARRAY as its array_type. The function freeing this parsed
data incorrectly tested the entry type for WPAS_DBUS_TYPE_ARRAY while doing
no testing of this value for array_type. This results in a memory leak
whenever a D-Bus message with this type of data is parsed.
Messages affected are:
fi.w1.wpa_supplicant1.Interface.P2PDevice
using RequestedDeviceTypes with Find method
using SecondaryDeviceTypes or VendorExtension with P2PDeviceProperties
fi.w1.wpa_supplicant1.Group
using WPSVendorExtensions with Properties property
All of the above messages are parsed with the same function,
wpa_dbus_dict_get_entry, so the assignment of the entry's type and
array_type is consistent. The parsed data is also consistently freed with
the same function, wpa_dbus_dict_entry_clear, so we can use the same checks
to free the data correctly.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Angie Chinchilla <angie.v.chinchilla@intel.com>
A number of fixes/improvements here:
1) Remove casting of getter/setter function types which allows
us to change the prototypes in the future and not have hard-to-find
runtime segfaults
2) Instead of having the getters create a fake reply message which
then gets its arguments copied into the real reply message, and is
then disposed, just pass message iters around and have them add
their arguments to the message itself
3) For setters, just pass in the message iter positioned at the
start of the argument list, instead of each setter having to skip
over the standard interface+property name
4) Convert error handling to use DBusError and return the error
back down through the call stacks to the function that will
actually send the error back to the caller, instead of having a
fake DBusMessage of type DBUS_MESSAGE_TYPE_ERROR that then
needs to have the error extracted from it.
But most of all, this fixes various segfaults (like rh #725517
and #678625) which were caused by some functions deep down in the
getter callpaths wanting a source DBusMessage* when the getters were
used for two things: signals (which don't have a source DBusMessage)
and methods (which will have a source DBusMessage that's being
replied to). This duality made the code fragile when handling
errors like invalid IEs over the air.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Some new code we're working on will require the dbus type "aay" (an
array of arrays of bytes). To add this, refactor the array code to
reduce code duplication by given a type string to the array starting
code, and also add code to create and parse such arrays from or into an
array of struct wpabuf respectively.
Since there's no unique DBus type for this, add a "fake"
WPAS_DBUS_TYPE_BINARRAY type that is separate from the regular DBus
types for parsing.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The array's type should be given as the proper
DBUS_TYPE_STRING_AS_STRING, but evidently it
doesn't matter since it's all packed into a
variant type.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The perror() calls do not make much sense with libdbus functions and
wpa_printf() would really be used for all error printing anyway. In
addition, many of the error messages on out-of-memory cases are not
really of much use, so they were removed. This is also cleaning up
some of the error path handling to avoid duplicated code.