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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Bob Copeland <[email protected]>

This looks reasonable to me - Alexis?

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to