From patchwork Tue May 26 18:06:23 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jesse Jones X-Patchwork-Id: 6484891 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 4BBD59F399 for ; Tue, 26 May 2015 18:06:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 44DE12065F for ; Tue, 26 May 2015 18:06:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 26F382065E for ; Tue, 26 May 2015 18:06:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751434AbbEZSG0 (ORCPT ); Tue, 26 May 2015 14:06:26 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:34828 "EHLO mail-qk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbbEZSGZ convert rfc822-to-8bit (ORCPT ); Tue, 26 May 2015 14:06:25 -0400 Received: by qkdn188 with SMTP id n188so96215882qkd.2 for ; Tue, 26 May 2015 11:06:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=wry/AJcedlEASvjVW/uLTd3V7TUDl+fGje9ILz/LgS8=; b=GjePne7EP9UZDlYh5yTe/Cvo6Y2cavbYdicjRgq6BB8AcMyvx087R2X64mlPAuETS7 gVWH3ll/I6RZWPJXDhQuuDWsWcsPj7JzCTsKxsW01Momn/jb3PWB3YPi+9nx8mk7WxmC WBY6Chzb39Jov6b2KF8W65kobPzW3NQ5PiNoQoczbv1SvxrvjBLA/k/ZEKzWCZ3SiNrf Chc8yd9vs+TodhYFFijKTwLTmFyFIlU13OT0NCJKPYrNOCizVz5ymbhdfOD/qlVdTt5U tRRLW9PrcjoZUhgIABoRb5GdQ3GL81gSHJHewl0B/8sq1hEFgX3FATSRARyfZcHoUJ0G EKfg== X-Gm-Message-State: ALoCoQmrTwZ5wTgm+InLJ1zYNKrdl0oM3jwVLi8QQetPWTr76LYXDClpDWT/fv1gDYn+QbmSfHvF X-Received: by 10.140.216.83 with SMTP id m80mr36742880qhb.14.1432663584764; Tue, 26 May 2015 11:06:24 -0700 (PDT) From: Jesse Jones References: <20150525161542.GA14318@localhost> In-Reply-To: <20150525161542.GA14318@localhost> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYag7JBrVaVAoxBrPJMyQ7e3bdzwEl2jv3nvW6OOA= Date: Tue, 26 May 2015 11:06:23 -0700 Message-ID: <3d7668c929311fbebc3309a3fc0c27d8@mail.gmail.com> Subject: RE: [PATCH] mac80211: fix a NULL dereference in ath9k (and likely other drivers) when fixed mesh paths are used To: Bob Copeland , Alexis Green Cc: Johannes Berg , linux-wireless Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Sounds good to me and I will try this though unfortunately not until next week when I get back from vacation. Thanks, Jesse -----Original Message----- From: Bob Copeland [mailto:me@bobcopeland.com] Sent: Monday, May 25, 2015 9:16 AM To: Alexis Green Cc: Johannes Berg; linux-wireless; Jesse Jones Subject: Re: [PATCH] mac80211: fix a NULL dereference in ath9k (and likely other drivers) when fixed mesh paths are used On Thu, May 21, 2015 at 06:05:13PM -0700, Alexis Green wrote: > This patch fixes a NULL dereference in ath9k (and likely other > drivers) when fixed mesh paths are used. The problem is that when a > station comes up sta_info_alloc allocates ath_node implicitly via > hw->sta_data_size. When it does that the ath_node is zeroed out. The > ath_node isn’t actually initialized until the station becomes associated > and ath9k_sta_state is called. Good catch. I wonder if we should instead remove the mesh special case in ieee80211_tx_h_check_assoc() -- given that we require an assoc station in peering before we send data frames to that RA, and userspace should also be setting assoc flag after MPM completes, I can't think of a reason offhand why we'd need to bail out there. Does this also fix the problem for you? It passed the wpa_supplicant test cases at least (but we aren't fixing mpaths in any of those...) From 246febaa51d555fda437cc8064798db06c5f4d6e Mon Sep 17 00:00:00 2001 From: Bob Copeland Date: Mon, 25 May 2015 12:01:52 -0400 Subject: [PATCH] mac80211: enable assoc check for mesh interfaces We already set a station to be associated when peering completes, both in user space and in the kernel. Thus we should always have an associated sta before sending data frames to that station. Failure to do this can cause crashes in the lower-level driver due to transmitting unicast data frames before driver sta structures (e.g. ampdu state in ath9k) are initialized. This could have happened if fixing mpaths, which could then allow TX to stations with whom we haven't yet completed peering. Reported-by: Alexis Green Signed-off-by: Bob Copeland --- net/mac80211/tx.c | 3 --- 1 file changed, 3 deletions(-) -- 2.1.4 diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 667111ee6a20..5787f15a3a12 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -301,9 +301,6 @@ ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx) if (tx->sdata->vif.type == NL80211_IFTYPE_WDS) return TX_CONTINUE; - if (tx->sdata->vif.type == NL80211_IFTYPE_MESH_POINT) - return TX_CONTINUE; - if (tx->flags & IEEE80211_TX_PS_BUFFERED) return TX_CONTINUE;