linux-stable.git/drivers/net/wireless, branch v4.13.7

brcmfmac: setup passive scan if requested by user-space

2017-10-12T09:56:18+00:00

commit 35f62727df0ed8e5e4857e162d94fd46d861f1cf upstream.

The driver was not properly configuring firmware with regard to the
type of scan. It always performed an active scan even when user-space
was requesting for passive scan, ie. the scan request was done without
any SSIDs specified.

Reported-by: Huang, Jiangyang 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: add length check in brcmf_cfg80211_escan_handler()

2017-10-12T09:56:18+00:00

commit 17df6453d4be17910456e99c5a85025aa1b7a246 upstream.

Upon handling the firmware notification for scans the length was
checked properly and may result in corrupting kernel heap memory
due to buffer overruns. This fix addresses CVE-2017-0786.

Cc: Kevin Cernekee 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD

2017-10-12T09:56:18+00:00

commit 97bce57bd7f96e1218751996f549a6e61f18cc8c upstream.

The MCAST_FILTER_CMD can get quite large when we have many mcast
addresses to set (we support up to 255).  So the command should be
send as NOCOPY to prevent a warning caused by too-long commands:

WARNING: CPU: 0 PID: 9700 at /root/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1550 iwl_pcie_enqueue_hcmd+0x8c7/0xb40 [iwlwifi]
Command MCAST_FILTER_CMD (0x1d0) is too large (328 bytes)

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196743

Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

mac80211_hwsim: Use proper TX power

2017-10-05T07:47:25+00:00

commit 9de981f507474f326e42117858dc9a9321331ae5 upstream.

In struct ieee80211_tx_info, control.vif pointer and rate_driver_data[0]
falls on the same place, depending on the union usage.
During the whole TX process, the union is referred to as a control struct,
which holds the vif that is later used in the tx flow, especially in order
to derive the used tx power.
Referring direcly to rate_driver_data[0] and assigning a value to it,
overwrites the vif pointer, hence making all later references irrelevant.
Moreover, rate_driver_data[0] isn't used later in the flow in order to
retrieve the channel that it is pointing to.

Signed-off-by: Beni Lev 
Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: add workaround to disable wide channels in 5GHz

2017-09-27T12:43:21+00:00

commit 01a9c948a09348950515bf2abb6113ed83e696d8 upstream.

The OTP in some SKUs have erroneously allowed 40MHz and 80MHz channels
in the 5.2GHz band.  The firmware has been modified to not allow this
in those SKUs, so the driver needs to do the same otherwise the
firmware will assert when we try to use it.

Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

wcn36xx: Introduce mutual exclusion of fw configuration

2017-09-27T12:43:14+00:00

commit 39efc7cc7ccf82d1cd946580cdb70760f347305a upstream.

As the association status changes the driver needs to configure the
hardware. This is done based on information in the "sta" acquired by
ieee80211_find_sta(), which requires the caller to ensure that the "sta"
is valid while its being used; generally by entering an rcu read
section.

But the operations acting on the "sta" has to communicate with the
firmware and may therefor sleep, resulting in the following report:

[   31.418190] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:238
[   31.425919] in_atomic(): 0, irqs_disabled(): 0, pid: 34, name:
kworker/u8:1
[   31.434609] CPU: 0 PID: 34 Comm: kworker/u8:1 Tainted: G        W
4.12.0-rc4-next-20170607+ #993
[   31.441002] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC
(DT)
[   31.450380] Workqueue: phy0 ieee80211_iface_work
[   31.457226] Call trace:
[   31.461830] [] dump_backtrace+0x0/0x260
[   31.464004] [] show_stack+0x14/0x20
[   31.469557] [] dump_stack+0x98/0xb8
[   31.474592] [] ___might_sleep+0xf0/0x118
[   31.479626] [] __might_sleep+0x50/0x88
[   31.485010] [] mutex_lock+0x24/0x60
[   31.490479] [] wcn36xx_smd_set_link_st+0x30/0x130
[   31.495428] [] wcn36xx_bss_info_changed+0x148/0x448
[   31.501504] []
ieee80211_bss_info_change_notify+0xbc/0x118
[   31.508102] [] ieee80211_assoc_success+0x664/0x7f8
[   31.515220] []
ieee80211_rx_mgmt_assoc_resp+0x144/0x2d8
[   31.521555] []
ieee80211_sta_rx_queued_mgmt+0x190/0x698
[   31.528239] [] ieee80211_iface_work+0x234/0x368
[   31.535011] [] process_one_work+0x1cc/0x340
[   31.541086] [] worker_thread+0x48/0x430
[   31.546814] [] kthread+0x108/0x138
[   31.552195] [] ret_from_fork+0x10/0x50

In order to ensure that the "sta" remains alive (and consistent) for the
duration of bss_info_changed() mutual exclusion has to be ensured with
sta_remove().

This is done by introducing a mutex to cover firmware configuration
changes, which is made to also ensure mutual exclusion between other
operations changing the state or configuration of the firmware. With
this we can drop the rcu read lock.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rt2800: fix TX_PIN_CFG setting for non MT7620 chips

2017-09-13T21:20:54+00:00

commit 83ec489193894e52bd395eec470f4f7c4286d4a5 upstream.

Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
initialize TX_PIN_CFG setting. This cause breakage at least on some
RT3573 devices. To fix the problem patch restores previous behaviour
for non MT7620 chips.

Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
Reported-and-tested-by: Jussi Eloranta 
Cc: Daniel Golle 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Daniel Golle 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices

2017-09-13T21:20:53+00:00

commit f957dd3c8db2781c8a334b166800788feb618625 upstream.

The firmware feature check introduced for multi-scheduled scan is also
failing for bcm4345 devices resulting in a firmware crash.
The reason for this crash has not yet been root cause so this patch avoids
the feature check for those device as a short-term fix.

Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature")
Signed-off-by: Ian W MORRISON 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: btcoexist: Fix antenna selection code

2017-09-13T21:20:52+00:00

commit 6d622692836950b3c943776f84c4557ff6c02f3b upstream.

In commit 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex"),
the code turns on a call to exhalbtc_bind_bt_coex_withadapter(). This
routine contains a bug that causes incorrect antenna selection for those
HP laptops with only one antenna and an incorrectly programmed EFUSE.
These boxes are the ones that need the ant_sel module parameter.

Fixes: 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex")
Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be

2017-09-13T21:20:52+00:00

commit a33fcba6ec01efcca33b1afad91057020f247f15 upstream.

In commit bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when
hw initialisation done"), there is an additional error when the module
parameter ant_sel is used to select the auxilary antenna. The error is
that the antenna selection is not checked when writing the antenna
selection register.

Fixes: bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when hw initialisation done")
Signed-off-by: Larry Finger 
Cc: Ping-Ke Shih 
Cc: Yan-Hsuan Chuang 
Cc: Birming Chiu 
Cc: Shaofu 
Cc: Steven Ting 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman