Stack overflow crash in interworking due to recursion

[Jouni Malinen]

On Fri, Jan 16, 2015 at 06:10:42PM +0100, Olsson, Ola wrote:
> We have observed a crash in the supplicant related to interworking on Android 5.
> 
> The stack trace looks like follows and we are not able to reproduce it manually (call chain goes upwards)
> 
> interworking_next_anqp_fetch
> interworking_start_fetch_anqp
> wpas_select_network_from_last_scan
> wpa_supplicant_fast_associate
> interworking_reconnect
> interworking_select_network

I was able to reproduce the loop and write an automated test case for
it, but my test build did not actually manage to run out of stack space
for some reason. Anyway, it did result in a five second busy loop
(followed by a scan and repeat..), so obviously not exactly desired
behavior.

This can be hit when auto_interworking=1 is used and there are no new
APs to query with ANQP and there is a BSS in scan result that has an
SSID matching one of the enabled network profiles, but not fully
matching security parameters.

> I was thinking about removing the call to "wpa_supplicant_fast_associate" in "interworking_reconnect" but if you have any better suggestions, please do tell.

While that would get rid of this issue, it would also disable a
significant optimization in Interworking connection speed. It's better
to modify this logic in a way that allows the fast path (i.e., skip a
new scan) to be used only once. This commit does that:
http://w1.fi/cgit/hostap/commit/?id=a8826b1848003eb84a6a287d4d71183ba2192dd6

In addition, I added another small change to reduce stack use:
http://w1.fi/cgit/hostap/commit/?id=edd5939a26da9860f65e195bca730f8687e9d3e8

Strictly speaking this commit is not required to avoid the main issue
here, but there is not much need for keeping so long call paths and
breaking them up with an eloop callback can be quite convenient
especially when there was already an existing callback handler that can
be reused for this. This gives some additional protection should similar
loops be possible in some other sequences (not that I found any when
reviewing this area).

-- 
Jouni Malinen                                            PGP id EFC895FA