[PATCH] P2P: Prevent p2p connect misuse

[Jouni Malinen]

On Tue, Dec 02, 2014 at 12:29:50PM +0100, 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.

P2P_CONNECT is an issue, but many of the other commands should work just
fine as-is since they go through the global P2P module regardless of
which struct wpa_supplicant instance was used to start them.

> 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).

After the change to make p2p_mgmt == 1 to reject various operations,
this won't result in association attempt, but anyway, group formation
would still fail.

> 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.

That should be "some p2p commands", not all.

> diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
> @@ -16,6 +16,7 @@
> +#include "p2p/p2p_i.h"

All src/*/*_i.h header files are internal to the implementation and not
allowed to be included into wpa_supplicant/*.c.

> @@ -4936,6 +4938,21 @@ int wpas_p2p_connect(struct wpa_supplicant *wpa_s, const u8 *peer_addr,
> +	p2p_wpa_s = wpa_s->global->p2p->cfg->cb_ctx;

That is not really good construction to use anyway.
wpa_s->global->p2p_init_wpa_s would be the proper way to do this.

> +	if (p2p_wpa_s != wpa_s) {
> +		wpa_printf(MSG_WARNING, "P2P: Cannot connect via %s. Use %s instead",
> +			   wpa_s->ifname, p2p_wpa_s->ifname);
> +		return -1;
> +	}

But this does not look ideal.. While some operations may be rejected,
but for most of the P2P use cases, it is straightforward to redirect the
operation to the correct context and it's probably best to do that to
avoid unexpected failures in cases that may have worked with drivers
that did not use P2P Device concept.

-- 
Jouni Malinen                                            PGP id EFC895FA