path: root/wpa_supplicant/p2p_supplicant.c
diff options
authorJouni Malinen <jouni@qca.qualcomm.com>2015-12-04 20:49:59 (GMT)
committerJouni Malinen <j@w1.fi>2015-12-04 20:49:59 (GMT)
commit63502c64e13d35dad591c315c8606866d9e07bce (patch)
treebe722c7f5927d7ecd78749346ec81d37be292d08 /wpa_supplicant/p2p_supplicant.c
parentf98b0e58061b7d8c84b8a31d0672b45025ffa63a (diff)
P2P: Fix P2P_CANCEL for p2p_in_invitation case
Commit f05cee9714ae87d315d893699a536b60a5aa73a9 ('P2P: Clear p2p_in_invitation on cancel') added a wpas_p2p_cancel() case to call wpas_p2p_group_formation_failed() if wpa_s->p2p_in_invitation is set. This is done in a loop going through wpa_s->next pointers. However, the call here can result in removing the interface and freeing wpa_s. The following attempt to read wpa_s->next is from freed memory and that can result in process termination when using a separate P2P group interface and issuing P2P_CANCEL on a group that was started through re-invocation of a persistent group. The recent commit 328f49acfe961a212e89e750516d2e2cc320765f ('P2P: Complete group formation on client data connection') "fixed" this by accident since wpa_s->p2p_in_invitation gets cleared in the sequence that could hit this issue and this results in P2P_CANCEL getting rejected. However, the real bug here is in the loop that continues after possible wpa_s instance deletion. Fix that by breaking out of the loop. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Diffstat (limited to 'wpa_supplicant/p2p_supplicant.c')
1 files changed, 1 insertions, 0 deletions
diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
index 077c5fe..f19bacc 100644
--- a/wpa_supplicant/p2p_supplicant.c
+++ b/wpa_supplicant/p2p_supplicant.c
@@ -7523,6 +7523,7 @@ int wpas_p2p_cancel(struct wpa_supplicant *wpa_s)
found = 1;
wpas_p2p_group_formation_failed(wpa_s, 0);
+ break;