From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:38152 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752430AbbGaBYN (ORCPT ); Thu, 30 Jul 2015 21:24:13 -0400 Subject: Patch "mac80211: prevent possible crypto tx tailroom corruption" has been added to the 4.1-stable tree To: michal.kazior@tieto.com, gregkh@linuxfoundation.org, johannes.berg@intel.com Cc: , From: Date: Thu, 30 Jul 2015 18:24:12 -0700 Message-ID: <143830585218170@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled mac80211: prevent possible crypto tx tailroom corruption to the 4.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: mac80211-prevent-possible-crypto-tx-tailroom-corruption.patch and it can be found in the queue-4.1 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From ab499db80fcf07c18e4053f91a619500f663e90e Mon Sep 17 00:00:00 2001 From: Michal Kazior Date: Fri, 22 May 2015 10:22:40 +0200 Subject: mac80211: prevent possible crypto tx tailroom corruption From: Michal Kazior commit ab499db80fcf07c18e4053f91a619500f663e90e upstream. There was a possible race between ieee80211_reconfig() and ieee80211_delayed_tailroom_dec(). This could result in inability to transmit data if driver crashed during roaming or rekeying and subsequent skbs with insufficient tailroom appeared. This race was probably never seen in the wild because a device driver would have to crash AND recover within 0.5s which is very unlikely. I was able to prove this race exists after changing the delay to 10s locally and crashing ath10k via debugfs immediately after GTK rekeying. In case of ath10k the counter went below 0. This was harmless but other drivers which actually require tailroom (e.g. for WEP ICV or MMIC) could end up with the counter at 0 instead of >0 and introduce insufficient skb tailroom failures because mac80211 would not resize skbs appropriately anymore. Fixes: 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when roaming") Signed-off-by: Michal Kazior Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- net/mac80211/main.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -249,6 +249,7 @@ static void ieee80211_restart_work(struc { struct ieee80211_local *local = container_of(work, struct ieee80211_local, restart_work); + struct ieee80211_sub_if_data *sdata; /* wait for scan work complete */ flush_workqueue(local->workqueue); @@ -257,6 +258,8 @@ static void ieee80211_restart_work(struc "%s called with hardware scan in progress\n", __func__); rtnl_lock(); + list_for_each_entry(sdata, &local->interfaces, list) + flush_delayed_work(&sdata->dec_tailroom_needed_wk); ieee80211_scan_cancel(local); ieee80211_reconfig(local); rtnl_unlock(); Patches currently in stable-queue which might be from michal.kazior@tieto.com are queue-4.1/cfg80211-ignore-netif-running-state-when-changing-iftype.patch queue-4.1/mac80211-prevent-possible-crypto-tx-tailroom-corruption.patch