linux-stable.git/drivers/net/wireless/ath, branch linux-4.13.y

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

ath10k: fix memory leak in rx ring buffer allocation

2017-09-09T15:39:23+00:00

commit f35a7f91f66af528b3ee1921de16bea31d347ab0 upstream.

The rx ring buffers are added to a hash table if
firmware support full rx reorder. If the full rx
reorder support flag is not set before allocating
the rx ring buffers, none of the buffers are added
to the hash table.

There is a race condition between rx ring refill and
rx buffer replenish from napi poll. The interrupts are
enabled in hif start, before the rx ring is refilled during init.
We replenish buffers from napi poll due to the interrupts which
get enabled after hif start. Hence before the entire rx ring is
refilled during the init, the napi poll replenishes a few buffers
in steps of 100 buffers per attempt. During this rx ring replenish
from napi poll, the rx reorder flag has not been set due to which
the replenished buffers are not added to the hash table

Set the rx full reorder support flag before we allocate
the rx ring buffer to avoid the memory leak.

Signed-off-by: Rakesh Pillai 
Signed-off-by: Kalle Valo 
Cc: Christian Lamparter 
Signed-off-by: Greg Kroah-Hartman

ath9k: remove useless variable assignment in ath_mci_intr()

2017-06-28T16:56:36+00:00

Value assigned to variable offset at line 551 is overwritten at line 562,
before it can be used. This makes such variable assignment useless.

Addresses-Coverity-ID: 1226941
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Kalle Valo

ath10k: fix a bunch of spelling mistakes in messages

2017-06-28T16:55:44+00:00

Fix the following spelling mistakes in messages:
  syncronise -> synchronize
  unusally -> unusually
  addrress -> address
  inverval -> interval

Signed-off-by: Colin Ian King 
Signed-off-by: Kalle Valo

ath9k: Use mutex_lock to avoid potential race in start/stop rng

2017-06-28T16:54:43+00:00

Move ath9k_rng_stop/ath9k_rng_start pair into critical section,
use mutex_lock to void potential race accessing.

Signed-off-by: Miaoqing Pan 
Signed-off-by: Kalle Valo

ath9k: avoid potential freezing during random generator read

2017-06-28T16:54:38+00:00

In the worst case, ath9k_rng_stop() may take 10s to stop rng kthread.
The time is too long for users, use wait_event_interruptible_timeout()
instead of msleep_interruptible(), wakup immediately once
kthread_should_stop() is true.

Signed-off-by: Miaoqing Pan 
Signed-off-by: Kalle Valo

ath9k: fix an invalid pointer dereference in ath9k_rng_stop()

2017-06-28T16:54:33+00:00

The bug was triggered when do suspend/resuming continuously
on Dell XPS L322X/0PJHXN version 9333 (2013) with kernel
4.12.0-041200rc4-generic. But can't reproduce on DELL
E5440 + AR9300 PCIE chips.

The warning is caused by accessing invalid pointer sc->rng_task.
sc->rng_task is not be cleared after kthread_stop(sc->rng_task)
be called in ath9k_rng_stop(). Because the kthread is stopped
before ath9k_rng_kthread() be scheduled.

So set sc->rng_task to null after kthread_stop(sc->rng_task) to
resolve this issue.

WARNING: CPU: 0 PID: 984 at linux/kernel/kthread.c:71 kthread_stop+0xf1/0x100
CPU: 0 PID: 984 Comm: NetworkManager Not tainted 4.12.0-041200rc4-generic #201706042031
Hardware name: Dell Inc.          Dell System XPS L322X/0PJHXN, BIOS A09 05/15/2013
task: ffff950170fdda00 task.stack: ffffa22c01538000
RIP: 0010:kthread_stop+0xf1/0x100
RSP: 0018:ffffa22c0153b5b0 EFLAGS: 00010246
RAX: ffffffffa6257800 RBX: ffff950171b79560 RCX: 0000000000000000
RDX: 0000000080000000 RSI: 000000007fffffff RDI: ffff9500ac9a9680
RBP: ffffa22c0153b5c8 R08: 0000000000000000 R09: 0000000000000000
R10: ffffa22c0153b648 R11: ffff9501768004b8 R12: ffff9500ac9a9680
R13: ffff950171b79f70 R14: ffff950171b78780 R15: ffff9501749dc018
FS:  00007f0d6bfd5540(0000) GS:ffff95017f200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc190161a08 CR3: 0000000232906000 CR4: 00000000001406f0
Call Trace:
  ath9k_rng_stop+0x1a/0x20 [ath9k]
  ath9k_stop+0x3b/0x1d0 [ath9k]
  drv_stop+0x33/0xf0 [mac80211]
  ieee80211_stop_device+0x43/0x50 [mac80211]
  ieee80211_do_stop+0x4f2/0x810 [mac80211]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196043
Reported-by: Giulio Genovese 
Tested-by: Giulio Genovese 
Cc: 
Signed-off-by: Miaoqing Pan 
Signed-off-by: Kalle Valo

ath10k: add const to thermal_cooling_device_ops structure

2017-06-28T16:53:40+00:00

Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_cooling_device_register and this
argument is of type const. So, declare the structure as const.

Signed-off-by: Bhumika Goyal 
Signed-off-by: Kalle Valo

ath9k: fix tx99 bus error

2017-06-28T16:52:26+00:00

The hard coded register 0x9864 and 0x9924 are invalid
for ar9300 chips.

Cc: 
Signed-off-by: Miaoqing Pan 
Signed-off-by: Kalle Valo

ath9k: fix tx99 use after free

2017-06-28T16:52:21+00:00

One scenario that could lead to UAF is two threads writing
simultaneously to the "tx99" debug file. One of them would
set the "start" value to true and follow to ath9k_tx99_init().
Inside the function it would set the sc->tx99_state to true
after allocating sc->tx99skb. Then, the other thread would
execute write_file_tx99() and call ath9k_tx99_deinit().
sc->tx99_state would be freed. After that, the first thread
would continue inside ath9k_tx99_init() and call
r = ath9k_tx99_send(sc, sc->tx99_skb, &txctl);
that would make use of the freed sc->tx99_skb memory.

Cc: 
Signed-off-by: Miaoqing Pan 
Signed-off-by: Kalle Valo