From patchwork Tue Jan 30 09:09:22 2018 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: 10191451 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 B6DE560388 for ; Tue, 30 Jan 2018 09:09:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AF9E5287F8 for ; Tue, 30 Jan 2018 09:09:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A2325288B5; Tue, 30 Jan 2018 09:09:44 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 AF268287F8 for ; Tue, 30 Jan 2018 09:09:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751219AbeA3JJl (ORCPT ); Tue, 30 Jan 2018 04:09:41 -0500 Received: from mail-lf0-f66.google.com ([209.85.215.66]:42462 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbeA3JJg (ORCPT ); Tue, 30 Jan 2018 04:09:36 -0500 Received: by mail-lf0-f66.google.com with SMTP id q17so14173117lfa.9 for ; Tue, 30 Jan 2018 01:09:36 -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:mime-version :content-transfer-encoding; bh=GG6QoJsCB4CKxs4KeXkaP1KYjffcbyq8qyAf7mRtMpw=; b=kdvP+0RiAZCQfCZw0foYpZwxZjVeJvGhe5OQQ0ZROkxTTdqeojJ48h0pZOdxI6DVK4 /X5Gnd1R8ymxen1qGyeMFJ2IsOITlBu+YLjBUo0iHr/f1yGX8TBhD7CQtdygL52CTPht qs0+pOBEglzFg+clx0a+XN2dTR4SjbmHJ6zO/NKIHhk8k2SjY9QZhtKGgWEPh3fFk7Z9 KTI+zz+PAKuDgju8BjJzRVamaj2ZpHj9+YsHqXoreqpS8ygLnDLgx2gmY+435WjVINah dLiT7e0lTCZ3kwiZmX1Amnmbr6SvapO/DBB/CoyhpzHAjZqEUhR2YdEdnsmhNpVz9ah9 GHMA== 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:mime-version :content-transfer-encoding; bh=GG6QoJsCB4CKxs4KeXkaP1KYjffcbyq8qyAf7mRtMpw=; b=cFZKBsYs1Mh0fCFVsVp7NGCfhrD1LJEZeLyDr+B+Zc+Wo5NFzBQp4lDxylK3aNmWhj wZIduF1XQPn+ZuJaG1yCscLyB6XsGfwoeY5wKI1uRGARxoKjkezsvtt8QPh7oZICzi3t l+1UWMCVn6ewC/MNSu8n0lyjaY0UlHz+Ag2sCGHUHbYMUlQqh46Rkn1rBEPGU8mAHTbO XaCkd7B84eliglzQPxvOtqX/TqPRpaSFsd8vjAIPWq4QvpfH6Tda1ykWafgnSilb3Kny LIq9ln/SDhh+Q/g4wIG8D5PNFF4A5SbxdKUOIdB07Pf6ACvA1yUFZZNWAnrFDrjcBD5w J59A== X-Gm-Message-State: AKwxyteF1d7CTckfARmtUysazi/CAYE/5eZTUW+BAnn8i1t45ouTbqRP Hpd5eYnZLtOmn94Z1q91vKI= X-Google-Smtp-Source: AH8x225Q2XYtQ7pu2t4jI53o2FL0Ta9GIXOTg3938zmuUXraHiW5H/V2Vqtz/mqDGCj1gRHxEJ/bsQ== X-Received: by 10.25.201.81 with SMTP id z78mr14684848lff.74.1517303375119; Tue, 30 Jan 2018 01:09:35 -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 r132sm3314299lfe.9.2018.01.30.01.09.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 01:09:34 -0800 (PST) From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= To: Kalle Valo Cc: Arend van Spriel , Franky Lin , Hante Meuleman , Chi-Hsien Lin , Wright Feng , Pieter-Paul Giesberts , linux-wireless@vger.kernel.org, brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list@cypress.com, =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Subject: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware Date: Tue, 30 Jan 2018 10:09:22 +0100 Message-Id: <20180130090922.30346-1-zajec5@gmail.com> X-Mailer: git-send-email 2.11.0 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 When using 4366b1 and 4366c0 chipsets with more recent firmwares 1) 10.10 (TOB) (r663589) 2) 10.10.122.20 (r683106) respectively, it is impossible to use brcmfmac with interface in AP mode. With the AP interface bridged and multicast used, no STA will be able to associate; the STA will be immediately disassociated when attempting to associate. Debugging revealed this to be caused by a "faked" packet (generated by firmware), that is passed to the networking subsystem and then back to the firmware. Fortunately this packet is easily identified and can be detected and ignored as a workaround for misbehaving firmware. Signed-off-by: Rafał Miłecki --- .../wireless/broadcom/brcm80211/brcmfmac/core.c | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c index 930e423f83a8..a98ba9bbc7fe 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c @@ -323,8 +323,54 @@ void brcmf_txflowblock_if(struct brcmf_if *ifp, spin_unlock_irqrestore(&ifp->netif_stop_lock, flags); } +/** + * brcmf_is_valid_skb - validates skb received from the hardware + * + * @skb: skb to check + * + * Sometimes firmware/hardware can generate broken packets that aren't real or + * valid and their skb-s shouldn't be passed up to the networking subsystem. + * + * Firmwares for 43602a1, 4366b1 and 4366c0 are known to *generate* a faked 6 B + * packet whenever a STA associates. The purpose of this fake packet remains + * unknown but it is clearly not data coming from a station. As such it + * shouldn't be passed to the networking subsystem. + * + * Normally such a packet would simply be ignored, but this is not the case with + * more recent 4366b1 and 4366c0 firmwares. These firmwares seem to explicitly + * check for this packet and will reject (disassociate) the station, making it + * impossible to connect to the AP at all. This can happen when using a bridged + * interface with multicasting. Such a scenario apparently isn't tested (or + * supported) by Broadcom's internal team. + */ +static bool brcmf_is_valid_skb(struct sk_buff *skb) +{ + const u8 fw_faked_packet[6] __aligned(2) = { + 0x00, 0x01, 0xaf, 0x81, 0x01, 0x00, + }; +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) + const u16 *a = (const u16 *)skb->data; + const u16 *b = (const u16 *)fw_faked_packet; +#endif + + if (skb->len != 6) + return true; + +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) + return !!(((*(const u32 *)skb->data) ^ (*(const u32 *)fw_faked_packet)) | + ((*(const u16 *)(skb->data + 4)) ^ (*(const u16 *)(fw_faked_packet + 4)))); +#else + return !!((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])); +#endif +} + void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb) { + if (!brcmf_is_valid_skb(skb)) { + brcmu_pkt_buf_free_skb(skb); + return; + } + if (skb->pkt_type == PACKET_MULTICAST) ifp->ndev->stats.multicast++;