After input PIN wrong 3 times, sim main state (include spn_watches)
is freed. but the watch id still be kept by other atoms (network and
gprs), when remove the atom, it will try to remove the watch from
spn_watches, ofono daemon will crash.
rs->imsi is only freed when rs->settings is true. So tweak the logic
inside radio_load_settings to only strdup the imsi when settings
creation has succeeded.
In some cases it is possible that a context is opened after a detach
event has been received, and right before an attach, depending on the
modem. We make sure that those contexts are removed to keep
consistency.
It works by looking for a context with the same APN and tries to use
that. Otherwise it will create it's own.
Then it assigns a gprs context driver and calls it's read_settings if
it exists.
When issuing a Scan() in poor reception while attached to an operator it's
fully possible to get no results, which causes the attached operator to be
cleaned up. In certain scenarios this would cause a use-after-free as there
are still references to this operator.
Transfer the attached operator to the new list regardless of removal caused
by the Scan() results.
This matches the behavior described by the documentation the signal
value returned by the code. This was causing a headache when using
stricter D-Bus wrappers like dbus-c++.
In situations where location changes rapidly, a use-after-free condition
can occur. What happens is that the timeout leaks and then the cbs
struct with the callback is cleaned up, resulting in a SIGSEGV when the
callback occurs from the glib loop.
When the voicecall atom is unregistered we remove all HFP support as
well but were supplying a zero as value to the emulator status
callbacks which caused the process to crash as we were dereferencing
the supplied value always and not respecting a zero as indicator to
reset.
When registering audio cards for the handsfree and gateway roles we
need a way for our users to differentiate between both to decide which
of them they start using for their purpose.
The kernel simply puts a null terminator at index 15 prior to ifr_name
processing. So we do the same.
Original report by:
Sabas Rosales, Blanca E <blanca.e.sabas.rosales@intel.com>
Buffer not null terminated (BUFFER_SIZE_WARNING) buffer_size_warning:
Calling strncpy with a maximum size argument of 16 bytes on destination
array ifr.ifr_ifrn.ifrn_name of size 16 bytes might leave the
destination string unterminated.
92 strncpy(ifr.ifr_name, interface, IFNAMSIZ);
Function: ag_features_list
static const char *list[10]; (Out of bounds write, line 75)
Incrementing i the value is now 10, for “hf-indicators”
Reported by: blanca.e.sabas.rosales@intel.com