From patchwork Fri May 22 08:22:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Kazior X-Patchwork-Id: 6461921 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7F343C0020 for ; Fri, 22 May 2015 08:23:00 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 95E3C2034E for ; Fri, 22 May 2015 08:22:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A2622202EB for ; Fri, 22 May 2015 08:22:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755276AbbEVIW5 (ORCPT ); Fri, 22 May 2015 04:22:57 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:37696 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbbEVIWy (ORCPT ); Fri, 22 May 2015 04:22:54 -0400 Received: by wibt6 with SMTP id t6so39099030wib.0 for ; Fri, 22 May 2015 01:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=e9uGSGrR2YsAY+TGQjt+V5W+z6W3GEjUZ1LUMbe44ls=; b=yhZnhRdeRlKYjGXbxF2s+cfSUD2VZRxv/k8wRQ7jwXvvWdRBjkv8r7O1YramyBN7t5 WDeFej8zCwmrLZBILOxRBhoVcYnk3bu2E92zY7C1OzBMvGpjiq0B+sOU+GlExSRPkZHm GCqQJJ5mOe4WC0Dqw0VU3F9XmYo+L0HGN7bdg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=e9uGSGrR2YsAY+TGQjt+V5W+z6W3GEjUZ1LUMbe44ls=; b=hh34rO2sMotoJNBqZAFENG5M/QK/GiO9UU7Io8DeYeqVKB6d5fy90BwmfSz2E8wxEJ Y1eIs8Tdkk0kkBH5UsXh16h7cQvfGXXXnpuSps9dcW9WPM0yj2OGTKyqWdC9SkajG9Ls x/HIVhZtFkj8OsPSyolfE6/ecnrrdchZDRt+NOdbwWrXN9SOeSILQFReb9PdjCHrlKgz OTSpw4Asc8Gsg7OMZTwf2kX9Z6twh/aBqXBP7FdTBGOh1Ic6CrcgZfYcj4Do8x7+URJy +inmOIlkj3NAhgLpL4Yl9NAhUhiSteNQaMQzvjc5Il77ysvXTFA/0WgJdC6DedB1Wm/n parA== X-Gm-Message-State: ALoCoQkr/Hyr/IrA2LfDe2aoPFPU6+39t3gD8NmHAtinuGD5lXvlcfkX4ruXlYuE7wm8n1j2yPIrD2+CDLReQb1rQrbPeEcyiY6IUpOjL3f3QPMwFJU9n5cT8PXT+Qg77NyRJ2iTPwbtlQlChsyz3u8+NSxiLUoALgdibjT/+SED/Yx+f6uTGDQerY8uGclDs575bhmU0pzk X-Received: by 10.194.143.75 with SMTP id sc11mr12628704wjb.62.1432282972806; Fri, 22 May 2015 01:22:52 -0700 (PDT) Received: from localhost.localdomain ([91.198.246.8]) by mx.google.com with ESMTPSA id k9sm6599363wia.6.2015.05.22.01.22.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 May 2015 01:22:51 -0700 (PDT) From: Michal Kazior To: linux-wireless@vger.kernel.org Cc: johannes@sipsolutions.net, Michal Kazior Subject: [PATCH v3] mac80211: prevent possible crypto tx tailroom corruption Date: Fri, 22 May 2015 10:22:40 +0200 Message-Id: <1432282960-4980-1-git-send-email-michal.kazior@tieto.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1431508609-9841-2-git-send-email-michal.kazior@tieto.com> References: <1431508609-9841-2-git-send-email-michal.kazior@tieto.com> X-DomainID: tieto.com 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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,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 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 --- Notes: v3: * use flush_work() [Johannes] net/mac80211/main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 99d27babd9f0..674164fe5cdb 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -246,6 +246,7 @@ static void ieee80211_restart_work(struct work_struct *work) { 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); @@ -254,6 +255,8 @@ static void ieee80211_restart_work(struct work_struct *work) "%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();