From patchwork Tue Jan 3 16:49:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= X-Patchwork-Id: 9495205 X-Patchwork-Delegate: kvalo@adurom.com 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 38CC860414 for ; Tue, 3 Jan 2017 16:50:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1D5F02793A for ; Tue, 3 Jan 2017 16:50:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0F22B27813; Tue, 3 Jan 2017 16:50:10 +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.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM 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 551F727813 for ; Tue, 3 Jan 2017 16:50:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965045AbdACQuF (ORCPT ); Tue, 3 Jan 2017 11:50:05 -0500 Received: from mail-lf0-f65.google.com ([209.85.215.65]:33961 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753120AbdACQto (ORCPT ); Tue, 3 Jan 2017 11:49:44 -0500 Received: by mail-lf0-f65.google.com with SMTP id d16so30597881lfb.1 for ; Tue, 03 Jan 2017 08:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JOwda7/odoDmc8uiur4COfH30LWO1WCXEoEOq87R0qg=; b=gGAGWHwLACZTZVLfk0NESrWtNFghevnq1oV22mY5BdgadI4kMj//HbTgV63AUdk9hF /8mM1E9b3NCR4aqmjDVha4Rrm3OfnfNH5uUU6JB6OpxkNqkWGzI1JBpIt4ZI1Yeyq+fy IWdJc5fsuACE+r4Ku0w3oqXrFMzNIYIA8aUl0q8NSScd/aajLRb20DjrJsQUidqXchEe tiU6s0CliWNn6qj+Bp0cbJ2iVmzKdhv+rPqhTbuHEolEqhGFjrgxcwb9irCwKdbyiONe WUv9TePC2JXBi6EgRDOlNd8AMmS4MTad7XalevNbDMKJwZy5M12F7dQvVAURgwX2OZjK +/bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JOwda7/odoDmc8uiur4COfH30LWO1WCXEoEOq87R0qg=; b=i8YLOx2ou4qr9orR7bCsTYMBB/xVNRlx3DnbQb2tyC1+54FA2cP7eZNZue4fxaTrIn 1toev7budGYS9+NQyCNXI2GosJRMgUtccWD7jImx0DjSmUWdv/1KoNAAzS80mFoPr5Qi MN/zRFJZDSQhdwTMjDiI+8Nw0oFJysykCxa9gNtag38ciAPafJEnjW7NxMrLjlYOFXBB OqQyVZl/dwSR0TQ9nu9Lgfsex1uuEmCvBk8K+I9ZY/2jXCBbOJUEFZ9bROdBF3VOI51U codk5xNC1Xc7JRwIrFDwu8iJGw4l4cThNN8BE1xjkr3JcREujcOGZxyRo0VhXGN/R2n3 X2hw== X-Gm-Message-State: AIkVDXILQ2Erq5sx4lMZrCV5apaMeIzceZBxIzkrPKcEzUvVj6H7L1N4e1HxhoDv6twjWw== X-Received: by 10.46.76.2 with SMTP id z2mr23562500lja.32.1483462182055; Tue, 03 Jan 2017 08:49:42 -0800 (PST) Received: from linux-samsung.lan (ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233]) by smtp.gmail.com with ESMTPSA id t26sm11540168lja.48.2017.01.03.08.49.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 08:49:41 -0800 (PST) From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= To: Kalle Valo Cc: Arend van Spriel , Franky Lin , Hante Meuleman , Pieter-Paul Giesberts , Franky Lin , linux-wireless@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com, =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Subject: [PATCH next V2] brcmfmac: avoid writing channel out of allocated array Date: Tue, 3 Jan 2017 17:49:30 +0100 Message-Id: <20170103164930.29989-1-zajec5@gmail.com> X-Mailer: git-send-email 2.10.1 In-Reply-To: <20170103083858.6981-1-zajec5@gmail.com> References: <20170103083858.6981-1-zajec5@gmail.com> MIME-Version: 1.0 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 From: Rafał Miłecki Our code was assigning number of channels to the index variable by default. If firmware reported channel we didn't predict this would result in using that initial index value and writing out of array. This never happened so far (we got a complete list of supported channels) but it means possible memory corruption so we should handle it anyway. This patch simply detects unexpected channel and ignores it. As we don't try to create new entry now, it's also safe to drop hw_value and center_freq assignment. For known channels we have these set anyway. I decided to fix this issue by assigning NULL or a target channel to the channel variable. This was one of possible ways, I prefefred this one as it also avoids using channel[index] over and over. Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy bands") Signed-off-by: Rafał Miłecki --- V2: Add extra comment in code for not-found channel. Make it clear this problem have never been seen so far Explain why it's safe to drop extra assignments Note & reason changing channel variable usage --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 32 ++++++++++++---------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 9c2c128..a16dd7b 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -5825,7 +5825,6 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg, u32 i, j; u32 total; u32 chaninfo; - u32 index; pbuf = kzalloc(BRCMF_DCMD_MEDLEN, GFP_KERNEL); @@ -5873,33 +5872,36 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg, ch.bw == BRCMU_CHAN_BW_80) continue; - channel = band->channels; - index = band->n_channels; + channel = NULL; for (j = 0; j < band->n_channels; j++) { - if (channel[j].hw_value == ch.control_ch_num) { - index = j; + if (band->channels[j].hw_value == ch.control_ch_num) { + channel = &band->channels[j]; break; } } - channel[index].center_freq = - ieee80211_channel_to_frequency(ch.control_ch_num, - band->band); - channel[index].hw_value = ch.control_ch_num; + if (!channel) { + /* It seems firmware supports some channel we never + * considered. Something new in IEEE standard? + */ + brcmf_err("Firmware reported unexpected channel %d\n", + ch.control_ch_num); + continue; + } /* assuming the chanspecs order is HT20, * HT40 upper, HT40 lower, and VHT80. */ if (ch.bw == BRCMU_CHAN_BW_80) { - channel[index].flags &= ~IEEE80211_CHAN_NO_80MHZ; + channel->flags &= ~IEEE80211_CHAN_NO_80MHZ; } else if (ch.bw == BRCMU_CHAN_BW_40) { - brcmf_update_bw40_channel_flag(&channel[index], &ch); + brcmf_update_bw40_channel_flag(channel, &ch); } else { /* enable the channel and disable other bandwidths * for now as mentioned order assure they are enabled * for subsequent chanspecs. */ - channel[index].flags = IEEE80211_CHAN_NO_HT40 | - IEEE80211_CHAN_NO_80MHZ; + channel->flags = IEEE80211_CHAN_NO_HT40 | + IEEE80211_CHAN_NO_80MHZ; ch.bw = BRCMU_CHAN_BW_20; cfg->d11inf.encchspec(&ch); chaninfo = ch.chspec; @@ -5907,11 +5909,11 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg, &chaninfo); if (!err) { if (chaninfo & WL_CHAN_RADAR) - channel[index].flags |= + channel->flags |= (IEEE80211_CHAN_RADAR | IEEE80211_CHAN_NO_IR); if (chaninfo & WL_CHAN_PASSIVE) - channel[index].flags |= + channel->flags |= IEEE80211_CHAN_NO_IR; } }