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

mwifiex: fix p2p device doesn't find in scan problem

2018-12-01T08:44:24+00:00

commit 3d8bd85c2c9e47ed2c82348aa5b6029ed48376ae upstream.

Marvell p2p device disappears from the list of p2p peers on the other
p2p device after disconnection.

It happens due to a bug in driver. When interface is changed from p2p
to station, certain variables(bss_type, bss_role etc.) aren't correctly
updated. This patch corrects them to fix the issue.

Signed-off-by: Karthik D A 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

mwifiex: Fix NULL pointer dereference in skb_dequeue()

2018-12-01T08:44:24+00:00

commit c44c040300d7afd79294710313a4989683e2afb1 upstream.

At couple of places in cleanup path, we are just going through the
skb queue and freeing them without unlinking. This leads to a crash
when other thread tries to do skb_dequeue() and use already freed node.

The problem is freed by unlinking skb before freeing it.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

mwifiex: report error to PCIe for suspend failure

2018-12-01T08:44:24+00:00

commit 5190f2e405919cd30ba2f12c58129fb2d71cd6b6 upstream.

When host_sleep_config command fails, we should return an error to
PCIe, instead of continuing (and possibly panicking, when we try to keep
processing a timed-out ioctl after we return "successfully" from
suspend).

Signed-off-by: Amitkumar Karwar 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

mwifiex: prevent register accesses after host is sleeping

2018-12-01T08:44:24+00:00

commit ec815dd2a5f110f627d7955e0027a3a008f68166 upstream.

Following is mwifiex driver-firmware host sleep handshake.
It involves three threads. suspend handler, interrupt handler, interrupt
processing in main work queue.

1) Enter suspend handler
2) Download HS_CFG command
3) Response from firmware for HS_CFG
4) Suspend thread waits until handshake completes(i.e hs_activate becomes
   true)
5) SLEEP from firmware
6) SLEEP confirm downloaded to firmware.
7) SLEEP confirm response from firmware
8) Driver processes SLEEP confirm response and set hs_activate to wake up
suspend thread
9) Exit suspend handler
10) Read sleep cookie in loop and wait until it indicates firmware is
sleep.
11) After processing SLEEP confirm response, we are at the end of interrupt
processing routine. Recheck if there are interrupts received while we were
processing them.

During suspend-resume stress test, it's been observed that we may end up
acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads
to a kernel crash.

This patch solves the problem with below changes.
a) action 10 above can be done before 8
b) Skip 11 if hs_activated is true. SLEEP confirm response
is the last interrupt from firmware. No need to recheck for
pending interrupts.
c) Add flush_workqueue() in suspend handler.

Signed-off-by: Amitkumar Karwar 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

cw1200: Don't leak memory if krealloc failes

2018-12-01T08:44:24+00:00

commit 9afdd6128c39f42398041bb2e017d8df0dcebcd1 upstream.

The call to krealloc() in wsm_buf_reserve() directly assigns the newly
returned memory to buf->begin. This is all fine except when krealloc()
failes we loose the ability to free the old memory pointed to by
buf->begin. If we just create a temporary variable to assign memory to
and assign the memory to it we can mitigate the memory leak.

Signed-off-by: Johannes Thumshirn 
Cc: Johannes Berg 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix kernel panic due to race in accessing arvif list

2018-12-01T08:44:21+00:00

commit ebaa4b1620bf69f2bc43cb45ea85fbafdaec23c3 upstream.

arvifs list is traversed within data_lock spin_lock in tasklet
context to fill channel information from the corresponding vif.
This means any access to arvifs list for add/del operations
should also be protected with the same spin_lock to avoid the
race. Fix this by performing list add/del on arvfis within the
data_lock. This could fix kernel panic something like the below.

 LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core]
 PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core]
 Internal error: Oops: 17 [#1] PREEMPT SMP ARM
 [] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core])
 [] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core])
 [] (tasklet_action+0x8c/0xec)
 [] (__do_softirq+0xdc/0x208)
 [] (irq_exit+0x84/0xe0)
 [] (__handle_domain_irq+0x80/0xa0)
 [] (gic_handle_irq+0x38/0x5c)
 [] (__irq_svc+0x40/0x74)

(gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0)
0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769)
764		struct cfg80211_chan_def def;
765
766		lockdep_assert_held(&ar->data_lock);
767
768		list_for_each_entry(arvif, &ar->arvifs, list) {
769			if (arvif->vdev_id == vdev_id &&
770			    ath10k_mac_vif_chan(arvif->vif, &def) == 0)
771				return def.chan;
772		}
773

Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: fix reporting support for 160 MHz channels

2018-12-01T08:44:18+00:00

commit d1fe6ad6f6bd61c84788d3a7b11e459a439c6169 upstream.

Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.

This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.

Signed-off-by: Rafał Miłecki 
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix regulatory domain update when the firmware starts

2018-12-01T08:44:18+00:00

commit 82715ac71e6b94a2c2136e31f3a8e6748e33aa8c upstream.

When the firmware starts, it doesn't have any regulatory
information, hence it uses the world wide limitations. The
driver can feed the firmware with previous knowledge that
was kept in the driver, but the firmware may still not
update its internal tables.

This happens when we start a BSS interface, and then the
firmware can change the regulatory tables based on our
location and it'll use more lenient, location specific
rules. Then, if the firmware is shut down (when the
interface is brought down), and then an AP interface is
created, the firmware will forget the country specific
rules.

The host will think that we are in a certain country that
may allow channels and will try to teach the firmware about
our location, but the firmware may still not allow to drop
the world wide limitations and apply country specific rules
because it was just re-started.

In this case, the firmware will reply with MCC_RESP_ILLEGAL
to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let
the upper layers (cfg80211 / hostapd) know that the channel
list they know about has been updated.

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

Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: support sta_statistics() even on older firmware

2018-12-01T08:44:18+00:00

commit ec484d03ef0df8d34086b95710e355a259cbe1f2 upstream.

The oldest firmware supported by iwlmvm do support getting
the average beacon RSSI. Enable the sta_statistics() call
from mac80211 even on older firmware versions.

Fixes: 33cef9256342 ("iwlwifi: mvm: support beacon statistics for BSS client")
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: check return value of rs_rate_from_ucode_rate()

2018-11-13T19:16:55+00:00

commit 3d71c3f1f50cf309bd20659422af549bc784bfff upstream.

The rs_rate_from_ucode_rate() function may return -EINVAL if the rate
is invalid, but none of the callsites check for the error, potentially
making us access arrays with index IWL_RATE_INVALID, which is larger
than the arrays, causing an out-of-bounds access.  This will trigger
KASAN warnings, such as the one reported in the bugzilla issue
mentioned below.

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

Cc: stable@vger.kernel.org
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman