From patchwork Sat Mar 24 10:29:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Wetzel X-Patchwork-Id: 10305941 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5C6AD600CC for ; Sat, 24 Mar 2018 11:07:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 46AC9289B5 for ; Sat, 24 Mar 2018 11:07:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3B3FB28B5B; Sat, 24 Mar 2018 11:07:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 52C33289B5 for ; Sat, 24 Mar 2018 11:07:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751905AbeCXLHE (ORCPT ); Sat, 24 Mar 2018 07:07:04 -0400 Received: from 7.mo69.mail-out.ovh.net ([46.105.50.32]:33193 "EHLO 7.mo69.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751843AbeCXLHD (ORCPT ); Sat, 24 Mar 2018 07:07:03 -0400 X-Greylist: delayed 1197 seconds by postgrey-1.27 at vger.kernel.org; Sat, 24 Mar 2018 07:07:03 EDT Received: from player687.ha.ovh.net (unknown [10.109.120.203]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id D11609966 for ; Sat, 24 Mar 2018 11:29:46 +0100 (CET) Received: from awhome.eu (p57B7EC03.dip0.t-ipconnect.de [87.183.236.3]) (Authenticated sender: postmaster@awhome.eu) by player687.ha.ovh.net (Postfix) with ESMTPSA id 8A0182C008C; Sat, 24 Mar 2018 11:29:44 +0100 (CET) From: Alexander Wetzel To: johannes@sipsolutions.net Cc: linux-wireless@vger.kernel.org, Alexander Wetzel Subject: [PATCH] mac80211: Fix wlan freezes under load at rekey Date: Sat, 24 Mar 2018 11:29:21 +0100 Message-Id: <20180324102921.9814-1-alexander.wetzel@web.de> X-Mailer: git-send-email 2.16.2 X-Ovh-Tracer-Id: 2925650911969238727 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrvdefgddujecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Rekeying a pairwise key with encryption offload and only keyid 0 has two potential races which can freeze the wlan conection till rekeyed again: 1) For incomming packets: If the local STA installs the key prior to the remote STA we still have the old key active in the hardware for a short time after mac80211 switched to the new key. The card can still hand over packets decoded with the old key to mac80211, bumping the new PN (IV) value to an incorrect high number and tricking the local replay detection to drop all packets really sent with the new key. 2) For outgoing packets: If mac80211 is providing the PN (IV) and hands over the cleartext packets for encryption to the hardware immediately prior to a key change the driver/card may process the queued packets after switching to the new key. This will immediatelly bump the PN (IV) value on the remote STA to an incorrect high number, also freezing the connection. Both issues can be prevented by deleting the key from the hardware prior to switching to the new key in mac80211, falling back to software encryption/decryption till the switch to the new key is completed. Signed-off-by: Alexander Wetzel --- net/mac80211/key.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/net/mac80211/key.c b/net/mac80211/key.c index aee05ec3f7ea..266ea0b507e7 100644 --- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -332,10 +332,15 @@ static void ieee80211_key_replace(struct ieee80211_sub_if_data *sdata, WARN_ON(new && old && new->conf.keyidx != old->conf.keyidx); - if (old) + if (old) { idx = old->conf.keyidx; - else + /* Make sure the card can't encrypt/decrypt packets with + * the old key prior to switching to new key in mac80211. + */ + ieee80211_key_disable_hw_accel(old); + } else { idx = new->conf.keyidx; + } if (sta) { if (pairwise) {