[PATCH] P2P: Prevent p2p connect misuse

Michal Kazior michal.kazior
Wed Dec 3 05:19:51 PST 2014


On 2 December 2014 at 17:13, Arend van Spriel <arend at broadcom.com> wrote:
> On 12/02/14 12:29, Michal Kazior wrote:
>>
>> It was possible to request p2p_connect (and possibly other callers like
>> p2p_prov_disc, and nfc-related stuff) on a different wpa_s context than
>> its subsequent related events were processed in causing failures.
>>
>> For example with dedicated p2pdev wpa_s->create_p2p_iface could be set
>> on, e.g. wlan1 but later wpas_go_neg_completed() was called for
>> p2p-dev-wlan1 whose create_p2p_iface was 0. This ended up with wpa_s
>> trying to use p2p-dev-wlan1 to associate (which isn't even a netdev).
>>
>> Steps to reproduce:
>>
>>   1. use driver with p2pdev
>>   2. start wpa_s, let wlan0 connect
>>   3. wpa_cli -i wlan0 p2p_find
>>   4. wpa_cli -i wlan0 p2p_connect ..
>>   5. p2p-dev-wlan0 tries to associate despite it's not even a netdev
>>
>> Obviously using p2p commands on non-main/p2p interface seems wrong and
>> steps (3) and (4) should be using p2p-dev-wlan0 instead. Nevertheless it
>> makes sense to prevent this misuse and warn the user in a sane way
>> instead of performing a cascade of strange failures.
>
>
> I thought steps (3) and (4) are global commands and would be forwarded to
> the (dedicated) p2p management interface.

Apparently that is not the case, at least as far as P2P_CONNECT and
wpas_p2p_connect() are concerned. I wonder if there are any other
commands which suffer from this kind of problem (i.e. silently assume
caller context is the same as event callback context at a later time)?


Micha?



More information about the Hostap mailing list