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

mwifiex: correct channel stat buffer overflows

2017-09-13T21:09:45+00:00

commit 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream.

mwifiex records information about various channels as it receives scan
information. It does this by appending to a buffer that was sized
to the max number of supported channels on any band, but there are
numerous problems:

(a) scans can return info from more than one band (e.g., both 2.4 and 5
    GHz), so the determined "max" is not large enough
(b) some firmware appears to return multiple results for a given
    channel, so the max *really* isn't large enough
(c) there is no bounds checking when stashing these stats, so problems
    (a) and (b) can easily lead to buffer overflows

Let's patch this by setting a slightly-more-correct max (that accounts
for a combination of both 2.4G and 5G bands) and adding a bounds check
when writing to our statistics buffer.

Due to problem (b), we still might not properly report all known survey
information (e.g., with "iw  survey dump"), since duplicate results
(or otherwise "larger than expected" results) will cause some
truncation. But that's a problem for a future bugfix.

(And because of this known deficiency, only log the excess at the WARN
level, since that isn't visible by default in this driver and would
otherwise be a bit too noisy.)

Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex")
Cc: Avinash Patil 
Cc: Xinming Hu 
Signed-off-by: Brian Norris 
Reviewed-by: Dmitry Torokhov 
Reviewed-by: Ganapathi Bhat 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl_pci_probe: Fix fail path of _rtl_pci_find_adapter

2017-09-13T21:09:45+00:00

commit fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream.

_rtl_pci_find_adapter fail path will jump to label fail3 for
unsupported adapter types.

However, on course for fail3 there will be call rtl_deinit_core
before rtl_init_core.

For the inclusion of checking pci_iounmap this fail can be moved to
fail2.

Fixes
[    4.492963] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi]

Signed-off-by: Malcolm Priestley 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix memory leak in rx ring buffer allocation

2017-09-13T21:09:44+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

wl1251: add a missing spin_lock_init()

2017-09-07T06:34:09+00:00

commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream.

wl1251: add a missing spin_lock_init()

This fixes the following kernel warning:

 [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
 [ 5668.771850]  lock: 0xce63ef20, .magic: 00000000, .owner: /-1,
 .owner_cpu: 0
 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G        W
 4.12.0-03002-gec979a4-dirty #40
 [ 5668.772796] Hardware name: Nokia RX-51 board
 [ 5668.773071] Workqueue: phy1 wl1251_irq_work
 [ 5668.773345] [] (unwind_backtrace) from []
 (show_stack+0x10/0x14)
 [ 5668.773803] [] (show_stack) from []
 (do_raw_spin_lock+0x6c/0xa0)
 [ 5668.774230] [] (do_raw_spin_lock) from []
 (_raw_spin_lock_irqsave+0x10/0x18)
 [ 5668.774658] [] (_raw_spin_lock_irqsave) from []
 (wl1251_op_tx+0x38/0x5c)
 [ 5668.775115] [] (wl1251_op_tx) from []
 (ieee80211_tx_frags+0x188/0x1c0)
 [ 5668.775543] [] (ieee80211_tx_frags) from []
 (__ieee80211_tx+0x6c/0x130)
 [ 5668.775970] [] (__ieee80211_tx) from []
 (ieee80211_tx+0xdc/0x104)
 [ 5668.776367] [] (ieee80211_tx) from []
 (__ieee80211_subif_start_xmit+0x454/0x8c8)
 [ 5668.776824] [] (__ieee80211_subif_start_xmit) from
 [] (ieee80211_subif_start_xmit+0x30/0x2fc)
 [ 5668.777343] [] (ieee80211_subif_start_xmit) from
 [] (dev_hard_start_xmit+0x80/0x118)
...

    by adding the missing spin_lock_init().

Reported-by: Pavel Machek 
Cc: Kalle Valo 
Signed-off-by: Cong Wang 
Acked-by: Pavel Machek 
Signed-off-by: Kalle Valo 
Signed-off-by: Pavel Machek 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

p54: memset(0) whole array

2017-09-02T05:06:51+00:00

commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream.

gcc 7 complains:
drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]

Fix that by passing the correct size to memset.

Signed-off-by: Jiri Slaby 
Cc: Christian Lamparter 
Cc: Kalle Valo 
Acked-by: Christian Lamparter 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

wil6210: fix deadlock when using fw_no_recovery option

2017-08-07T02:19:41+00:00

commit dfb5b098e0f40b68aa07f2ec55f4dd762efefbfa upstream.

When FW crashes with no_fw_recovery option, driver
waits for manual recovery with wil->mutex held, this
can easily create deadlocks.
Fix the problem by moving the wait outside the lock.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix null deref on wmi-tlv when trying spectral scan

2017-08-07T02:19:41+00:00

commit 18ae68fff392e445af3c2d8be9bef8a16e1c72a7 upstream.

WMI ops wrappers did not properly check for null
function pointers for spectral scan. This caused
null dereference crash with WMI-TLV based firmware
which doesn't implement spectral scan.

The crash could be triggered with:

  ip link set dev wlan0 up
  echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl

The crash looked like this:

  [  168.031989] BUG: unable to handle kernel NULL pointer dereference at           (null)
  [  168.037406] IP: [<          (null)>]           (null)
  [  168.040395] PGD cdd4067 PUD fa0f067 PMD 0
  [  168.043303] Oops: 0010 [#1] SMP
  [  168.045377] Modules linked in: ath10k_pci(O) ath10k_core(O) ath mac80211 cfg80211 [last unloaded: cfg80211]
  [  168.051560] CPU: 1 PID: 1380 Comm: bash Tainted: G        W  O    4.8.0 #78
  [  168.054336] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
  [  168.059183] task: ffff88000c460c00 task.stack: ffff88000d4bc000
  [  168.061736] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
  ...
  [  168.100620] Call Trace:
  [  168.101910]  [] ? ath10k_spectral_scan_config+0x96/0x200 [ath10k_core]
  [  168.104871]  [] ? filemap_fault+0xb2/0x4a0
  [  168.106696]  [] write_file_spec_scan_ctl+0x116/0x280 [ath10k_core]
  [  168.109618]  [] full_proxy_write+0x51/0x80
  [  168.111443]  [] __vfs_write+0x28/0x120
  [  168.113090]  [] ? security_file_permission+0x3d/0xc0
  [  168.114932]  [] ? percpu_down_read+0x12/0x60
  [  168.116680]  [] vfs_write+0xb8/0x1a0
  [  168.118293]  [] SyS_write+0x46/0xa0
  [  168.119912]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
  [  168.121737] Code:  Bad RIP value.
  [  168.123318] RIP  [<          (null)>]           (null)

Signed-off-by: Michal Kazior 
Signed-off-by: Kalle Valo 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

wlcore: fix 64K page support

2017-07-27T22:06:04+00:00

commit 4a4274bf2dbbd1c7a45be0c89a1687c9d2eef4a0 upstream.

In the stable linux-3.16 branch, I ran into a warning in the
wlcore driver:

drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write':
drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

Newer kernels no longer show the warning, but the bug is still there,
as the allocation is based on the CPU page size rather than the
actual capabilities of the hardware.

This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes
per buffer.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix tx99 bus error

2017-07-27T22:06:02+00:00

commit bde717ab473668377fc65872398a102d40cb2d58 upstream.

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

Signed-off-by: Miaoqing Pan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix tx99 use after free

2017-07-27T22:06:02+00:00

commit cf8ce1ea61b75712a154c93e40f2a5af2e4dd997 upstream.

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.

Signed-off-by: Miaoqing Pan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman