From adc8b374e3818a3d71dde22de6d2b8a72ccaf540 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Tue, 8 Jan 2019 08:27:26 +0100 Subject: [PATCH] mac80211: brcmfmac: backport fixes from the 5.0-rc1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 --- ...-brcmfmac-support-STA-info-struct-v7.patch | 80 +++++++++++++ ...rcmf_dmi_probe-before-brcmf_of_probe.patch | 39 +++++++ ...-of-bounds-memory-access-during-fw-l.patch | 110 ++++++++++++++++++ 3 files changed, 229 insertions(+) create mode 100644 package/kernel/mac80211/patches/brcm/325-v5.0-brcmfmac-support-STA-info-struct-v7.patch create mode 100644 package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch create mode 100644 package/kernel/mac80211/patches/brcm/327-v5.0-brcmfmac-Fix-out-of-bounds-memory-access-during-fw-l.patch diff --git a/package/kernel/mac80211/patches/brcm/325-v5.0-brcmfmac-support-STA-info-struct-v7.patch b/package/kernel/mac80211/patches/brcm/325-v5.0-brcmfmac-support-STA-info-struct-v7.patch new file mode 100644 index 00000000000..8ff42462b04 --- /dev/null +++ b/package/kernel/mac80211/patches/brcm/325-v5.0-brcmfmac-support-STA-info-struct-v7.patch @@ -0,0 +1,80 @@ +From 4282ff17e557d319e1b988fa4f582792cfaf6fff Mon Sep 17 00:00:00 2001 +From: Dan Haab +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 +Reviewed-by: Rafał Miłecki +Reviewed-by: Arend van Spriel +Signed-off-by: Kalle Valo +--- + .../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 { diff --git a/package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch b/package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch new file mode 100644 index 00000000000..01621561c18 --- /dev/null +++ b/package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch @@ -0,0 +1,39 @@ +From 554da3868eb1d7174710c18b4ddd6ff01f6d612c Mon Sep 17 00:00:00 2001 +From: Hans de Goede +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 +Tested-and-reported-by: Peter Robinson +Signed-off-by: Hans de Goede +Signed-off-by: Kalle Valo +--- + 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; + } diff --git a/package/kernel/mac80211/patches/brcm/327-v5.0-brcmfmac-Fix-out-of-bounds-memory-access-during-fw-l.patch b/package/kernel/mac80211/patches/brcm/327-v5.0-brcmfmac-Fix-out-of-bounds-memory-access-during-fw-l.patch new file mode 100644 index 00000000000..0ed148188b0 --- /dev/null +++ b/package/kernel/mac80211/patches/brcm/327-v5.0-brcmfmac-Fix-out-of-bounds-memory-access-during-fw-l.patch @@ -0,0 +1,110 @@ +From b72c51a58e6d63ef673ac96b8ab5bc98799c5f7b Mon Sep 17 00:00:00 2001 +From: Lyude Paul +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 +Cc: Pieter-Paul Giesberts +Cc: Franky Lin +Cc: Arend van Spriel +Cc: Kalle Valo +Cc: Arend Van Spriel +Cc: Himanshu Jha +Cc: Dan Haab +Cc: Jia-Shyr Chuang +Cc: Ian Molton +Cc: # v4.17+ +Signed-off-by: Lyude Paul +Signed-off-by: Kalle Valo +--- + .../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++) { -- 2.30.2