kernel/drivers/net/wireless/marvell, branch linux-5.1.y

mwifiex: Don't abort on small, spec-compliant vendor IEs

2019-07-14T06:09:49Z

commit 63d7ef36103d26f20325a921ecc96a3288560146 upstream. Per the 802.11 specification, vendor IEs are (at minimum) only required to contain an OUI. A type field is also included in ieee80211.h (struct ieee80211_vendor_ie) but doesn't appear in the specification. The remaining fields (subtype, version) are a convention used in WMM headers. Thus, we should not reject vendor-specific IEs that have only the minimum length (3 bytes) -- we should skip over them (since we only want to match longer IEs, that match either WMM or WPA formats). We can reject elements that don't have the minimum-required 3 byte OUI. While we're at it, move the non-standard subtype and version fields into the WMM structs, to avoid this confusion in the future about generic "vendor header" attributes. Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element") Cc: Takashi Iwai Signed-off-by: Brian Norris Reviewed-by: Takashi Iwai Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

mwifiex: Abort at too short BSS descriptor element

2019-07-14T06:09:48Z

commit 685c9b7750bfacd6fc1db50d86579980593b7869 upstream. Currently mwifiex_update_bss_desc_with_ie() implicitly assumes that the source descriptor entries contain the enough size for each type and performs copying without checking the source size. This may lead to read over boundary. Fix this by putting the source size check in appropriate places. Signed-off-by: Takashi Iwai Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

mwifiex: Fix heap overflow in mwifiex_uap_parse_tail_ies()

2019-07-14T06:09:38Z

[ Upstream commit 69ae4f6aac1578575126319d3f55550e7e440449 ] A few places in mwifiex_uap_parse_tail_ies() perform memcpy() unconditionally, which may lead to either buffer overflow or read over boundary. This patch addresses the issues by checking the read size and the destination size at each place more properly. Along with the fixes, the patch cleans up the code slightly by introducing a temporary variable for the token size, and unifies the error path with the standard goto statement. Reported-by: huangwen Signed-off-by: Takashi Iwai Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

mwifiex: Fix possible buffer overflows at parsing bss descriptor

2019-07-14T06:09:37Z

[ Upstream commit 13ec7f10b87f5fc04c4ccbd491c94c7980236a74 ] mwifiex_update_bss_desc_with_ie() calls memcpy() unconditionally in a couple places without checking the destination size. Since the source is given from user-space, this may trigger a heap buffer overflow. Fix it by putting the length check before performing memcpy(). This fix addresses CVE-2019-3846. Reported-by: huangwen Signed-off-by: Takashi Iwai Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

mwifiex: Fix mem leak in mwifiex_tm_cmd

2019-05-31T13:43:39Z

[ Upstream commit 003b686ace820ce2d635a83f10f2d7f9c147dabc ] 'hostcmd' is alloced by kzalloc, should be freed before leaving from the error handling cases, otherwise it will cause mem leak. Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support") Signed-off-by: YueHaibing Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

mwifiex: prevent an array overflow

2019-05-31T13:43:23Z

[ Upstream commit b4c35c17227fe437ded17ce683a6927845f8c4a4 ] The "rate_index" is only used as an index into the phist_data->rx_rate[] array in the mwifiex_hist_data_set() function. That array has MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some debugfs information. The "rate_index" variable comes from the network skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap it to prevent an array overflow. Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin

mwl8k: Fix rate_idx underflow

2019-05-16T17:35:35Z

commit 6b583201fa219b7b1b6aebd8966c8fd9357ef9f4 upstream. It was reported on OpenWrt bug tracking system[1], that several users are affected by the endless reboot of their routers if they configure 5GHz interface with channel 44 or 48. The reboot loop is caused by the following excessive number of WARN_ON messages: WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516 ieee80211_rx_napi+0x1fc/0xa54 [mac80211] as the messages are being correctly emitted by the following guard: case RX_ENC_LEGACY: if (WARN_ON(status->rate_idx >= sband->n_bitrates)) as the rate_idx is in this case erroneously set to 251 (0xfb). This fix simply converts previously used magic number to proper constant and guards against substraction which is leading to the currently observed underflow. 1. https://bugs.openwrt.org/index.php?do=details&task_id=2218 Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive") Cc: Tested-by: Eubert Bao Reported-by: Eubert Bao Signed-off-by: Petr Štetiar Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

mwifiex: Make resume actually do something useful again on SDIO cards

2019-04-25T11:05:14Z

The commit fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent adapter status variables") had a fairly straightforward bug in it. It contained this bit of diff: - if (!adapter->is_suspended) { + if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) { As you can see the patch missed the "!" when converting to the atomic bitops. This meant that the resume hasn't done anything at all since that commit landed and suspend/resume for mwifiex SDIO cards has been totally broken. After fixing this mwifiex suspend/resume appears to work again, at least with the simple testing I've done. Fixes: fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent adapter status variables") Cc: Signed-off-by: Douglas Anderson Reviewed-by: Brian Norris Signed-off-by: Kalle Valo

libertas_tf: get the MAC address before registering the device

2019-02-20T17:55:54Z

The start() callback is too late for this: NetworkManager would already have seen the hardware, thinking 00:00:00:00:00:00 is its permanent address. Signed-off-by: Lubomir Rintel Reviewed-by: Steve deRosier Signed-off-by: Kalle Valo

libertas_tf: don't defer firmware loading until start()

2019-02-20T17:55:54Z

In order to be able to get a MAC address before we register the device with ieee80211 we'll need to load the firmware way earlier. There seems to be one problem with this: the device seems to start with radio enabled and starts sending in frames right after the firmware load finishes. Disable the radio as soon as possible. Signed-off-by: Lubomir Rintel Reviewed-by: Steve deRosier Signed-off-by: Kalle Valo