linux-stable.git/drivers/net/wireless, branch v3.16.52

brcmfmac: Add check for short event packets

2018-01-01T20:51:46+00:00

commit dd2349121bb1b8ff688c3ca6a2a0bea9d8c142ca upstream.

The length of the data in the received skb is currently passed into
brcmf_fweh_process_event() as packet_len, but this value is not checked.
event_packet should be followed by DATALEN bytes of additional event
data.  Ensure that the received packet actually contains at least
DATALEN bytes of additional data, to avoid copying uninitialized memory
into event->data.

Suggested-by: Mattias Nissler 
Signed-off-by: Kevin Cernekee 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

brcmfmac: Add length checks on firmware events

2018-01-01T20:51:46+00:00

commit 0aedbcaf6f182690790d98d90d5fe1e64c846c34 upstream.

Add additional length checks on firmware events to create more
robust code.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Lei Zhang 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
[bwh: Backported to 3.16:
 - Drop changes to brcmf_wowl_nd_results()
 - Adjust filenames, context]
Signed-off-by: Ben Hutchings

iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD

2018-01-01T20:51:29+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/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 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

mac80211_hwsim: Use proper TX power

2017-11-26T13:50:31+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 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

iwlwifi: mvm: Avoid deferring non bufferable frames

2017-11-26T13:50:27+00:00

commit eb045e6e0389eabfd704dd7a76d8b2a892970e85 upstream.

Use bcast station for all non bufferable frames on AP and AD-HOC.

The host is no longer aware of STAs PS status because of buffer
station offload, so we can't rely on mac80211 to toggle on
IEEE80211_TX_CTL_NO_PS_BUFFER bit.

A possible issue with buffering such frames, beside the obvious spec
violation, is when a station disconnects while in PS but the AP isn't
aware of that. In such scenarios the AP won't be able to send probe
responses or auth frames so the STA won't be able to reconnect and
the AP will have a queue hang.

Fixes: 3e56eadfb6a1 ("iwlwifi: mvm: implement AP/GO uAPSD support")
Signed-off-by: David Spinadel 
Signed-off-by: Luca Coelho 
Signed-off-by: Ben Hutchings

iwlwifi: mvm: simplify bufferable MMPDU check

2017-11-26T13:50:27+00:00

commit 7426ee33a29b3215357986378c77bb9949518154 upstream.

There's no need to spell out the cases when we can just
use ieee80211_is_bufferable_mmpdu().

Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

iwlwifi: pci: add new PCI ID for 7265D

2017-11-26T13:50:20+00:00

commit 3f7a5e13e85026b6e460bbd6e87f87379421d272 upstream.

We have a new PCI subsystem ID for 7265D.  Add it to the list.

Signed-off-by: Luca Coelho 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

wcn36xx: Remove unnecessary rcu_read_unlock in wcn36xx_bss_info_changed

2017-11-26T13:50:16+00:00

commit c0d5adc35c0b010120391117cb07be6623cf8940 upstream.

No rcu_read_lock is called, but rcu_read_unlock is still called.
Thus rcu_read_unlock should be removed.

Signed-off-by: Jia-Ju Bai 
Acked-by: Bjorn Andersson 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings

wcn36xx: Introduce mutual exclusion of fw configuration

2017-11-26T13:50:16+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 
[bwh: Backported to 3.16:
 - Drop changes in wcn36xx_configure_filter(), which doesn't change state
 - Adjust context]
Signed-off-by: Ben Hutchings

brcmfmac: avoid gcc-5.1 warning

2017-11-11T13:33:54+00:00

commit 22f44150aad7a1d6b074ab6cf59abee61c7187c6 upstream.

gcc-5.0 gained a new warning in the fwsignal portion of the brcmfmac
driver:

drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c: In function 'brcmf_fws_txs_process':
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]

This is a false positive, and marking the brcmf_fws_hanger_poppkt function
as 'static inline' makes the warning go away. I have checked the object
file output and while a little code gets moved around, the size of
the binary remains identical.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings