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

b43: Fix error in cordic routine

2019-01-13T09:07:12+00:00

commit 8ea3819c0bbef57a51d8abe579e211033e861677 upstream.

The cordic routine for calculating sines and cosines that was added in
commit 6f98e62a9f1b ("b43: update cordic code to match current specs")
contains an error whereby a quantity declared u32 can in fact go negative.

This problem was detected by Priit Laes who is switching b43 to use the
routine in the library functions of the kernel.

Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)")
Reported-by: Priit Laes 
Cc: Rafał Miłecki 
Cc: Stable  # 2.6.34
Signed-off-by: Larry Finger 
Signed-off-by: Priit Laes 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

wil6210: missing length check in wmi_set_ie

2018-12-21T13:08:49+00:00

commit b5a8ffcae4103a9d823ea3aa3a761f65779fbe2a upstream.

Add a length check in wmi_set_ie to detect unsigned integer
overflow.

Signed-off-by: Lior David 
Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

Revert "wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()"

2018-12-13T08:22:27+00:00

This reverts commit cbc56a12da05d5333a9020c4d7854ad7d0b5a31d which was
upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1.

From Dietmar May's report on the stable mailing list
(https://www.spinics.net/lists/stable/msg272201.html):

> I've run into some problems which appear due to (a) recent patch(es) on
> the wlcore wifi driver.
>
> 4.4.160 - commit 3fdd34643ffc378b5924941fad40352c04610294
> 4.9.131 - commit afeeecc764436f31d4447575bb9007732333818c
>
> Earlier versions (4.9.130 and 4.4.159 - tested back to 4.4.49) do not
> exhibit this problem. It is still present in 4.9.141.
>
> master as of 4.20.0-rc4 does not exhibit this problem.
>
> Basically, during client association when in AP mode (running hostapd),
> handshake may or may not complete following a noticeable delay. If
> successful, then the driver fails consistently in warn_slowpath_null
> during disassociation. If unsuccessful, the wifi client attempts multiple
> times, sometimes failing repeatedly. I've had clients unable to connect
> for 3-5 minutes during testing, with the syslog filled with dozens of
> backtraces. syslog details are below.
>
> I'm working on an embedded device with a TI 3352 ARM processor and a
> murata wl1271 module in sdio mode. We're running a fully patched ubuntu
> 18.04 ARM build, with a kernel built from kernel.org's stable/linux repo .
> Relevant parts of the kernel config are included below.
>
> The commit message states:
>
> > /I've only seen this few times with the runtime PM patches enabled so
> > this one is probably not needed before that. This seems to work
> > currently based on the current PM implementation timer. Let's apply
> > this separately though in case others are hitting this issue./
> We're not doing anything explicit with power management. The device is an
> IoT edge gateway with battery backup, normally running on wall power. The
> battery is currently used solely to shut down the system cleanly to avoid
> filesystem corruption.
>
> The device tree is configured to keep power in suspend; but the device
> should never suspend, so in our case, there is no need to call
> wl1271_ps_elp_wakeup() or wl1271_ps_elp_sleep(), as occurs in the patch.

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cw1200: Don't leak memory if krealloc failes

2018-12-01T08:48:04+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: schedule hardware restart if WMI command times out

2018-11-22T06:32:42+00:00

[ Upstream commit a9911937e7d332761e8c4fcbc7ba0426bdc3956f ]

When running in AP mode, ath10k sometimes suffers from TX credit
starvation. The issue is hard to reproduce and shows up once in a
few days, but has been repeatedly seen with QCA9882 and a large
range of firmwares, including 10.2.4.70.67.

Once the module is in this state, TX credits are never replenished,
which results in "SWBA overrun" errors, as no beacons can be sent.
Even worse, WMI commands run in a timeout while holding the conf
mutex for three seconds each, making any further operations slow
and the whole system unresponsive.

The firmware/driver never recovers from that state automatically,
and triggering TX flush or warm restarts won't work over WMI. So
issue a hardware restart if a WMI command times out due to missing
TX credits. This implies a connectivity outage of about 1.4s in AP
mode, but brings back the interface and the whole system to a usable
state. WMI command timeouts have not been seen in absent of this
specific issue, so taking such drastic actions seems legitimate.

Signed-off-by: Martin Willi 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: correctly define 7265-D cfg

2018-11-10T15:39:20+00:00

[ Upstream commit 2b0e2b0f7bfe9a9098bda6109176adcf78f9b7ac ]

The trans cfg was not replaced for 7265-D cards. This led to a check of
the min-NVM version against a 7265-C card, causing very-old 7265-D cards
to operate incorrectly with the driver.

Fixes: 3fd0d3c170ad ("iwlwifi: pcie: support 7265-D devices")
Signed-off-by: Arik Nemtsov 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Sasha Levin

rtlwifi: rtl8821ae: Fix lockups on boot

2018-11-10T15:39:19+00:00

[ Upstream commit eeec5d0ef7ee54a75e09e861c3cc44177b8752c7 ]

In commit 54328e64047a5 ("rtlwifi: rtl8821ae: Fix system lockups on boot"),
an attempt was made to fix a regression introduced in commit 1277fa2ab2f9
("rtlwifi: Remove the clear interrupt routine from all drivers").
Unfortunately, there were logic errors in that patch that prevented
affected boxes from booting even after that patch was applied.

The actual cause of the original problem is unknown as none of the
developers have systems that are affected.

Fixes: 54328e64047a ("rtlwifi: rtl8821ae: Fix system lockups on boot")
Signed-off-by: Larry Finger 
Cc: Stable  [V4.1+]
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

rtlwifi: rtl8821ae: Fix system lockups on boot

2018-11-10T15:39:19+00:00

[ Upstream commit 54328e64047a54b8fc2362c2e1f0fa16c90f739f ]

In commit 1277fa2ab2f9 ("rtlwifi: Remove the clear interrupt routine from all
drivers"), the code that cleared all interrupt enable bits before setting them
was removed for all PCI drivers. This fixed an issue that caused TX to be
blocked for 3-5 seconds. On some RTL8821AE units, this change causes soft
lockups to occur on boot. For that reason, the portion of the earlier commit
that applied to rtl8821ae is reverted. Kernels 4.1 and newer are affected.

See http://marc.info/?l=linux-wireless&m=144373370103285&w=2 and
https://bugzilla.opensuse.org/show_bug.cgi?id=944978 for two cases where
this regression affected user systems. Note that this bug does not appear on
any of the developer's setups. For those users whose systems are affected
by the TX blockage, but do not lock up on boot, a module parameter is added
to disable the interrupt clear

Fixes: 1277fa2ab2f9 ("rtlwifi: Remove the clear interrupt routine from all drivers")
Signed-off-by: Larry Finger 
Cc: Stable  [V4.1+]
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()

2018-10-13T07:09:26+00:00

[ Upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1 ]

Otherwise we can get:

WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84

I've only seen this few times with the runtime PM patches enabled
so this one is probably not needed before that. This seems to
work currently based on the current PM implementation timer. Let's
apply this separately though in case others are hitting this issue.

Signed-off-by: Tony Lindgren 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()

2018-10-13T07:09:26+00:00

[ Upstream commit ae636fb1554833ee5133ca47bf4b2791b6739c52 ]

This is a static checker fix, not something I have tested.  The issue
is that on the second iteration through the loop, we jump forward by
le32_to_cpu(auth_req->length) bytes.  The problem is that if the length
is more than "buflen" then we end up with a negative "buflen".  A
negative buflen is type promoted to a high positive value and the loop
continues but it's accessing beyond the end of the buffer.

I believe the "auth_req->length" comes from the firmware and if the
firmware is malicious or buggy, you're already toasted so the impact of
this bug is probably not very severe.

Fixes: 030645aceb3d ("rndis_wlan: handle 802.11 indications from device")
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman