From: Johannes Berg <johannes@sipsolutions.net>
To: Bob Copeland <me@bobcopeland.com>
Cc: Alexis Green <agreen@cococorp.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
Jesse Jones <jjones@cococorp.com>
Subject: Re: [PATCH] mac80211: fix a NULL dereference in ath9k (and likely other drivers) when fixed mesh paths are used
Date: Tue, 26 May 2015 15:27:53 +0200 [thread overview]
Message-ID: <1432646873.5169.7.camel@sipsolutions.net> (raw)
In-Reply-To: <20150525161542.GA14318@localhost> (sfid-20150525_181607_881541_7801FE28)
On Mon, 2015-05-25 at 12:15 -0400, Bob Copeland wrote:
> 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 <me@bobcopeland.com>
> 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 <agreen@cococorp.com>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
This looks reasonable to me - Alexis?
johannes
next prev parent reply other threads:[~2015-05-26 13:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 1:05 [PATCH] mac80211: fix a NULL dereference in ath9k (and likely other drivers) when fixed mesh paths are used Alexis Green
2015-05-25 16:15 ` Bob Copeland
2015-05-26 13:27 ` Johannes Berg [this message]
2015-05-26 18:06 ` Jesse Jones
2015-06-12 18:01 ` Jesse Jones
2015-06-12 20:10 ` Johannes Berg
2015-06-12 22:33 ` Bob Copeland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1432646873.5169.7.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=agreen@cococorp.com \
--cc=jjones@cococorp.com \
--cc=linux-wireless@vger.kernel.org \
--cc=me@bobcopeland.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.