mirror of
https://github.com/openwrt/openwrt.git
synced 2024-12-22 06:57:57 +00:00
mac80211: brcmfmac: backport fixes from the 5.0-rc1
This fixes: 1) Getting STA info with newer firmwares 2) Getting DMI / UEFI / OF data 3) Possible memory corruption in firmware loading code Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This commit is contained in:
parent
df57d71a1a
commit
adc8b374e3
@ -0,0 +1,80 @@
|
|||||||
|
From 4282ff17e557d319e1b988fa4f582792cfaf6fff Mon Sep 17 00:00:00 2001
|
||||||
|
From: Dan Haab <riproute@gmail.com>
|
||||||
|
Date: Fri, 9 Nov 2018 09:38:55 -0700
|
||||||
|
Subject: [PATCH] brcmfmac: support STA info struct v7
|
||||||
|
MIME-Version: 1.0
|
||||||
|
Content-Type: text/plain; charset=UTF-8
|
||||||
|
Content-Transfer-Encoding: 8bit
|
||||||
|
|
||||||
|
The newest firmwares provide STA info using v7 of the struct. As v7
|
||||||
|
isn't backward compatible, a union is needed.
|
||||||
|
|
||||||
|
Even though brcmfmac does not use any of the new info it's important to
|
||||||
|
provide the proper struct buffer. Without this change new firmwares will
|
||||||
|
fallback to the very limited v3 instead of something in between such as
|
||||||
|
v4.
|
||||||
|
|
||||||
|
Signed-off-by: Dan Haab <dan.haab@luxul.com>
|
||||||
|
Reviewed-by: Rafał Miłecki <rafal@milecki.pl>
|
||||||
|
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
|
||||||
|
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
||||||
|
---
|
||||||
|
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 40 +++++++++++++++----
|
||||||
|
1 file changed, 33 insertions(+), 7 deletions(-)
|
||||||
|
|
||||||
|
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
|
||||||
|
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
|
||||||
|
@@ -176,6 +176,8 @@
|
||||||
|
|
||||||
|
#define BRCMF_VHT_CAP_MCS_MAP_NSS_MAX 8
|
||||||
|
|
||||||
|
+#define BRCMF_HE_CAP_MCS_MAP_NSS_MAX 8
|
||||||
|
+
|
||||||
|
/* MAX_CHUNK_LEN is the maximum length for data passing to firmware in each
|
||||||
|
* ioctl. It is relatively small because firmware has small maximum size input
|
||||||
|
* playload restriction for ioctls.
|
||||||
|
@@ -601,13 +603,37 @@ struct brcmf_sta_info_le {
|
||||||
|
__le32 rx_pkts_retried; /* # rx with retry bit set */
|
||||||
|
__le32 tx_rate_fallback; /* lowest fallback TX rate */
|
||||||
|
|
||||||
|
- /* Fields valid for ver >= 5 */
|
||||||
|
- struct {
|
||||||
|
- __le32 count; /* # rates in this set */
|
||||||
|
- u8 rates[BRCMF_MAXRATES_IN_SET]; /* rates in 500kbps units w/hi bit set if basic */
|
||||||
|
- u8 mcs[BRCMF_MCSSET_LEN]; /* supported mcs index bit map */
|
||||||
|
- __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX]; /* supported mcs index bit map per nss */
|
||||||
|
- } rateset_adv;
|
||||||
|
+ union {
|
||||||
|
+ struct {
|
||||||
|
+ struct {
|
||||||
|
+ __le32 count; /* # rates in this set */
|
||||||
|
+ u8 rates[BRCMF_MAXRATES_IN_SET]; /* rates in 500kbps units w/hi bit set if basic */
|
||||||
|
+ u8 mcs[BRCMF_MCSSET_LEN]; /* supported mcs index bit map */
|
||||||
|
+ __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX]; /* supported mcs index bit map per nss */
|
||||||
|
+ } rateset_adv;
|
||||||
|
+ } v5;
|
||||||
|
+
|
||||||
|
+ struct {
|
||||||
|
+ __le32 rx_dur_total; /* total user RX duration (estimated) */
|
||||||
|
+ __le16 chanspec; /** chanspec this sta is on */
|
||||||
|
+ __le16 pad_1;
|
||||||
|
+ struct {
|
||||||
|
+ __le16 version; /* version */
|
||||||
|
+ __le16 len; /* length */
|
||||||
|
+ __le32 count; /* # rates in this set */
|
||||||
|
+ u8 rates[BRCMF_MAXRATES_IN_SET]; /* rates in 500kbps units w/hi bit set if basic */
|
||||||
|
+ u8 mcs[BRCMF_MCSSET_LEN]; /* supported mcs index bit map */
|
||||||
|
+ __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX]; /* supported mcs index bit map per nss */
|
||||||
|
+ __le16 he_mcs[BRCMF_HE_CAP_MCS_MAP_NSS_MAX]; /* supported he mcs index bit map per nss */
|
||||||
|
+ } rateset_adv; /* rateset along with mcs index bitmap */
|
||||||
|
+ __le16 wpauth; /* authentication type */
|
||||||
|
+ u8 algo; /* crypto algorithm */
|
||||||
|
+ u8 pad_2;
|
||||||
|
+ __le32 tx_rspec; /* Rate of last successful tx frame */
|
||||||
|
+ __le32 rx_rspec; /* Rate of last successful rx frame */
|
||||||
|
+ __le32 wnm_cap; /* wnm capabilities */
|
||||||
|
+ } v7;
|
||||||
|
+ };
|
||||||
|
};
|
||||||
|
|
||||||
|
struct brcmf_chanspec_list {
|
@ -0,0 +1,39 @@
|
|||||||
|
From 554da3868eb1d7174710c18b4ddd6ff01f6d612c Mon Sep 17 00:00:00 2001
|
||||||
|
From: Hans de Goede <hdegoede@redhat.com>
|
||||||
|
Date: Fri, 23 Nov 2018 10:11:48 +0100
|
||||||
|
Subject: [PATCH] brcmfmac: Call brcmf_dmi_probe before brcmf_of_probe
|
||||||
|
|
||||||
|
ARM systems with UEFI may have both devicetree (of) and DMI data in this
|
||||||
|
case we end up setting brcmf_mp_device.board_type twice.
|
||||||
|
|
||||||
|
In this case we should prefer the devicetree data, because:
|
||||||
|
1) The devicerree data is more reliable
|
||||||
|
2) Some ARM systems (e.g. the Raspberry Pi 3 models) support both UEFI and
|
||||||
|
classic uboot booting, the devicetree data is always there, so using it
|
||||||
|
makes sure we ask for the same nvram file independent of how we booted.
|
||||||
|
|
||||||
|
This commit moves the brcmf_dmi_probe call to before the brcmf_of_probe
|
||||||
|
call, so that the latter can override the value of the first if both are
|
||||||
|
set.
|
||||||
|
|
||||||
|
Fixes: bd1e82bb420a ("brcmfmac: Set board_type from DMI on x86 based ...")
|
||||||
|
Cc: Peter Robinson <pbrobinson@gmail.com>
|
||||||
|
Tested-and-reported-by: Peter Robinson <pbrobinson@gmail.com>
|
||||||
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
||||||
|
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
||||||
|
---
|
||||||
|
drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
|
||||||
|
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||||
|
|
||||||
|
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
|
||||||
|
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
|
||||||
|
@@ -449,8 +449,8 @@ struct brcmf_mp_device *brcmf_get_module
|
||||||
|
}
|
||||||
|
if (!found) {
|
||||||
|
/* No platform data for this device, try OF and DMI data */
|
||||||
|
- brcmf_of_probe(dev, bus_type, settings);
|
||||||
|
brcmf_dmi_probe(settings, chip, chiprev);
|
||||||
|
+ brcmf_of_probe(dev, bus_type, settings);
|
||||||
|
}
|
||||||
|
return settings;
|
||||||
|
}
|
@ -0,0 +1,110 @@
|
|||||||
|
From b72c51a58e6d63ef673ac96b8ab5bc98799c5f7b Mon Sep 17 00:00:00 2001
|
||||||
|
From: Lyude Paul <lyude@redhat.com>
|
||||||
|
Date: Sat, 24 Nov 2018 17:57:05 -0500
|
||||||
|
Subject: [PATCH] brcmfmac: Fix out of bounds memory access during fw load
|
||||||
|
|
||||||
|
I ended up tracking down some rather nasty issues with f2fs (and other
|
||||||
|
filesystem modules) constantly crashing on my kernel down to a
|
||||||
|
combination of out of bounds memory accesses, one of which was coming
|
||||||
|
from brcmfmac during module load:
|
||||||
|
|
||||||
|
[ 30.891382] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
|
||||||
|
[ 30.894437] ==================================================================
|
||||||
|
[ 30.901581] BUG: KASAN: global-out-of-bounds in brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
|
||||||
|
[ 30.909935] Read of size 1 at addr ffff2000024865df by task kworker/6:2/387
|
||||||
|
[ 30.916805]
|
||||||
|
[ 30.918261] CPU: 6 PID: 387 Comm: kworker/6:2 Tainted: G O 4.20.0-rc3Lyude-Test+ #19
|
||||||
|
[ 30.927251] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
|
||||||
|
[ 30.935964] Workqueue: events brcmf_driver_register [brcmfmac]
|
||||||
|
[ 30.941641] Call trace:
|
||||||
|
[ 30.944058] dump_backtrace+0x0/0x3e8
|
||||||
|
[ 30.947676] show_stack+0x14/0x20
|
||||||
|
[ 30.950968] dump_stack+0x130/0x1c4
|
||||||
|
[ 30.954406] print_address_description+0x60/0x25c
|
||||||
|
[ 30.959066] kasan_report+0x1b4/0x368
|
||||||
|
[ 30.962683] __asan_report_load1_noabort+0x18/0x20
|
||||||
|
[ 30.967547] brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
|
||||||
|
[ 30.967639] brcmf_sdio_probe+0x163c/0x2050 [brcmfmac]
|
||||||
|
[ 30.978035] brcmf_ops_sdio_probe+0x598/0xa08 [brcmfmac]
|
||||||
|
[ 30.983254] sdio_bus_probe+0x190/0x398
|
||||||
|
[ 30.983270] really_probe+0x2a0/0xa70
|
||||||
|
[ 30.983296] driver_probe_device+0x1b4/0x2d8
|
||||||
|
[ 30.994901] __driver_attach+0x200/0x280
|
||||||
|
[ 30.994914] bus_for_each_dev+0x10c/0x1a8
|
||||||
|
[ 30.994925] driver_attach+0x38/0x50
|
||||||
|
[ 30.994935] bus_add_driver+0x330/0x608
|
||||||
|
[ 30.994953] driver_register+0x140/0x388
|
||||||
|
[ 31.013965] sdio_register_driver+0x74/0xa0
|
||||||
|
[ 31.014076] brcmf_sdio_register+0x14/0x60 [brcmfmac]
|
||||||
|
[ 31.023177] brcmf_driver_register+0xc/0x18 [brcmfmac]
|
||||||
|
[ 31.023209] process_one_work+0x654/0x1080
|
||||||
|
[ 31.032266] worker_thread+0x4f0/0x1308
|
||||||
|
[ 31.032286] kthread+0x2a8/0x320
|
||||||
|
[ 31.039254] ret_from_fork+0x10/0x1c
|
||||||
|
[ 31.039269]
|
||||||
|
[ 31.044226] The buggy address belongs to the variable:
|
||||||
|
[ 31.044351] brcmf_firmware_path+0x11f/0xfffffffffffd3b40 [brcmfmac]
|
||||||
|
[ 31.055601]
|
||||||
|
[ 31.057031] Memory state around the buggy address:
|
||||||
|
[ 31.061800] ffff200002486480: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
|
||||||
|
[ 31.068983] ffff200002486500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||||
|
[ 31.068993] >ffff200002486580: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
|
||||||
|
[ 31.068999] ^
|
||||||
|
[ 31.069017] ffff200002486600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||||
|
[ 31.096521] ffff200002486680: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
|
||||||
|
[ 31.096528] ==================================================================
|
||||||
|
[ 31.096533] Disabling lock debugging due to kernel taint
|
||||||
|
|
||||||
|
It appears that when trying to determine the length of the string in the
|
||||||
|
alternate firmware path, we make the mistake of not handling the case
|
||||||
|
where the firmware path is empty correctly. Since strlen(mp_path) can
|
||||||
|
return 0, we'll end up accessing mp_path[-1] when the firmware_path
|
||||||
|
isn't provided through the module arguments.
|
||||||
|
|
||||||
|
So, fix this by just setting the end char to '\0' by default, and only
|
||||||
|
changing it if we have a non-zero length. Additionally, use strnlen()
|
||||||
|
with BRCMF_FW_ALTPATH_LEN instead of strlen() just to be extra safe.
|
||||||
|
|
||||||
|
Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function")
|
||||||
|
Cc: Hante Meuleman <hante.meuleman@broadcom.com>
|
||||||
|
Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
|
||||||
|
Cc: Franky Lin <franky.lin@broadcom.com>
|
||||||
|
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
|
||||||
|
Cc: Kalle Valo <kvalo@codeaurora.org>
|
||||||
|
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
|
||||||
|
Cc: Himanshu Jha <himanshujha199640@gmail.com>
|
||||||
|
Cc: Dan Haab <dhaab@luxul.com>
|
||||||
|
Cc: Jia-Shyr Chuang <saint.chuang@cypress.com>
|
||||||
|
Cc: Ian Molton <ian@mnementh.co.uk>
|
||||||
|
Cc: <stable@vger.kernel.org> # v4.17+
|
||||||
|
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
||||||
|
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
||||||
|
---
|
||||||
|
.../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 8 ++++++--
|
||||||
|
1 file changed, 6 insertions(+), 2 deletions(-)
|
||||||
|
|
||||||
|
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
|
||||||
|
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
|
||||||
|
@@ -708,8 +708,9 @@ brcmf_fw_alloc_request(u32 chip, u32 chi
|
||||||
|
struct brcmf_fw_request *fwreq;
|
||||||
|
char chipname[12];
|
||||||
|
const char *mp_path;
|
||||||
|
+ size_t mp_path_len;
|
||||||
|
u32 i, j;
|
||||||
|
- char end;
|
||||||
|
+ char end = '\0';
|
||||||
|
size_t reqsz;
|
||||||
|
|
||||||
|
for (i = 0; i < table_size; i++) {
|
||||||
|
@@ -734,7 +735,10 @@ brcmf_fw_alloc_request(u32 chip, u32 chi
|
||||||
|
mapping_table[i].fw_base, chipname);
|
||||||
|
|
||||||
|
mp_path = brcmf_mp_global.firmware_path;
|
||||||
|
- end = mp_path[strlen(mp_path) - 1];
|
||||||
|
+ mp_path_len = strnlen(mp_path, BRCMF_FW_ALTPATH_LEN);
|
||||||
|
+ if (mp_path_len)
|
||||||
|
+ end = mp_path[mp_path_len - 1];
|
||||||
|
+
|
||||||
|
fwreq->n_items = n_fwnames;
|
||||||
|
|
||||||
|
for (j = 0; j < n_fwnames; j++) {
|
Loading…
Reference in New Issue
Block a user