From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ey0-f174.google.com ([209.85.215.174]:32875 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751987Ab1IVSjE (ORCPT ); Thu, 22 Sep 2011 14:39:04 -0400 Received: by eya28 with SMTP id 28so1775116eya.19 for ; Thu, 22 Sep 2011 11:39:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1316691605.3899.43.camel@jlt3.sipsolutions.net> References: <1316082334-7664-1-git-send-email-arik@wizery.com> <1316082334-7664-3-git-send-email-arik@wizery.com> <1316606713.3940.29.camel@jlt3.sipsolutions.net> <1316691605.3899.43.camel@jlt3.sipsolutions.net> From: Arik Nemtsov Date: Thu, 22 Sep 2011 21:38:48 +0300 Message-ID: (sfid-20110922_203908_350819_038830DD) Subject: Re: [RFC 2/5] mac80211: handle TDLS high-level commands and frames To: Johannes Berg Cc: Kalyan C Gaddam , Jouni Malinen , linux-wireless@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, Sep 22, 2011 at 14:40, Johannes Berg wrote: >> The race is even worse - from queuing until the actual Tx, we could >> have disconnected from this AP and connected do a totally different >> one. But this shouldn't happen in reality (and we can add some guards >> to wpa_supplicant to make sure). >> Do you see this as a security threat? > > I don't really know :-) I just saw the possible race here. If you remove > the TDLS station entries when disassociating then it shouldn't be an > issue, right? Since you require a station entry pretty early on anyway. As discussed on IRC - this race is not really an issue. In the next version of the patch stations will be purged by kernel-mode on disassociation. Arik