linux-stable.git/drivers/net/wireless/ath, branch linux-4.12.y Linux kernel stable tree ath10k: fix memory leak in rx ring buffer allocation 2017-09-09T15:39:31+00:00 Rakesh Pillai pillair@qti.qualcomm.com 2017-08-02T10:33:37+00:00 d49ea1b6f98fe0298381a8bb0b082686f48ef77b 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 <pillair@qti.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Cc: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <pillair@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath9k: fix an invalid pointer dereference in ath9k_rng_stop() 2017-07-27T22:10:03+00:00 Miaoqing Pan miaoqing@codeaurora.org 2017-06-27T14:31:53+00:00 a1b6a2c3592b7a4d2a12b31fc5c4c38706a3f8f9 commit 07246c115801c27652700e3679bb58661ef7ed65 upstream. 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 <giulio.genovese@gmail.com> Tested-by: Giulio Genovese <giulio.genovese@gmail.com> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 07246c115801c27652700e3679bb58661ef7ed65 upstream.

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 <giulio.genovese@gmail.com>
Tested-by: Giulio Genovese <giulio.genovese@gmail.com>
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath9k: fix tx99 bus error 2017-07-27T22:10:03+00:00 Miaoqing Pan miaoqing@codeaurora.org 2017-06-27T14:31:51+00:00 e9fe79bcf1a7f0121fc97b0ac0c80b7878117521 commit bde717ab473668377fc65872398a102d40cb2d58 upstream. The hard coded register 0x9864 and 0x9924 are invalid for ar9300 chips. Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bde717ab473668377fc65872398a102d40cb2d58 upstream.

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

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath9k: fix tx99 use after free 2017-07-27T22:10:03+00:00 Miaoqing Pan miaoqing@codeaurora.org 2017-06-27T14:31:49+00:00 33c147af30973b25d04014342e42292bd31f0996 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 <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: Fix inconsistent teardown and release of private netdev state. 2017-06-07T19:53:24+00:00 David S. Miller davem@davemloft.net 2017-05-08T16:52:56+00:00 cf124db566e6b036b8bcbe8decbed740bdfac8c6 Network devices can allocate reasources and private memory using netdev_ops->ndo_init(). However, the release of these resources can occur in one of two different places. Either netdev_ops->ndo_uninit() or netdev->destructor(). The decision of which operation frees the resources depends upon whether it is necessary for all netdev refs to be released before it is safe to perform the freeing. netdev_ops->ndo_uninit() presumably can occur right after the NETDEV_UNREGISTER notifier completes and the unicast and multicast address lists are flushed. netdev->destructor(), on the other hand, does not run until the netdev references all go away. Further complicating the situation is that netdev->destructor() almost universally does also a free_netdev(). This creates a problem for the logic in register_netdevice(). Because all callers of register_netdevice() manage the freeing of the netdev, and invoke free_netdev(dev) if register_netdevice() fails. If netdev_ops->ndo_init() succeeds, but something else fails inside of register_netdevice(), it does call ndo_ops->ndo_uninit(). But it is not able to invoke netdev->destructor(). This is because netdev->destructor() will do a free_netdev() and then the caller of register_netdevice() will do the same. However, this means that the resources that would normally be released by netdev->destructor() will not be. Over the years drivers have added local hacks to deal with this, by invoking their destructor parts by hand when register_netdevice() fails. Many drivers do not try to deal with this, and instead we have leaks. Let's close this hole by formalizing the distinction between what private things need to be freed up by netdev->destructor() and whether the driver needs unregister_netdevice() to perform the free_netdev(). netdev->priv_destructor() performs all actions to free up the private resources that used to be freed by netdev->destructor(), except for free_netdev(). netdev->needs_free_netdev is a boolean that indicates whether free_netdev() should be done at the end of unregister_netdevice(). Now, register_netdevice() can sanely release all resources after ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit() and netdev->priv_destructor(). And at the end of unregister_netdevice(), we invoke netdev->priv_destructor() and optionally call free_netdev(). Signed-off-by: David S. Miller <davem@davemloft.net> 
Network devices can allocate reasources and private memory using
netdev_ops->ndo_init().  However, the release of these resources
can occur in one of two different places.

Either netdev_ops->ndo_uninit() or netdev->destructor().

The decision of which operation frees the resources depends upon
whether it is necessary for all netdev refs to be released before it
is safe to perform the freeing.

netdev_ops->ndo_uninit() presumably can occur right after the
NETDEV_UNREGISTER notifier completes and the unicast and multicast
address lists are flushed.

netdev->destructor(), on the other hand, does not run until the
netdev references all go away.

Further complicating the situation is that netdev->destructor()
almost universally does also a free_netdev().

This creates a problem for the logic in register_netdevice().
Because all callers of register_netdevice() manage the freeing
of the netdev, and invoke free_netdev(dev) if register_netdevice()
fails.

If netdev_ops->ndo_init() succeeds, but something else fails inside
of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
it is not able to invoke netdev->destructor().

This is because netdev->destructor() will do a free_netdev() and
then the caller of register_netdevice() will do the same.

However, this means that the resources that would normally be released
by netdev->destructor() will not be.

Over the years drivers have added local hacks to deal with this, by
invoking their destructor parts by hand when register_netdevice()
fails.

Many drivers do not try to deal with this, and instead we have leaks.

Let's close this hole by formalizing the distinction between what
private things need to be freed up by netdev->destructor() and whether
the driver needs unregister_netdevice() to perform the free_netdev().

netdev->priv_destructor() performs all actions to free up the private
resources that used to be freed by netdev->destructor(), except for
free_netdev().

netdev->needs_free_netdev is a boolean that indicates whether
free_netdev() should be done at the end of unregister_netdevice().

Now, register_netdevice() can sanely release all resources after
ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
and netdev->priv_destructor().

And at the end of unregister_netdevice(), we invoke
netdev->priv_destructor() and optionally call free_netdev().

Signed-off-by: David S. Miller <davem@davemloft.net>
wcn36xx: Close SMD channel on device removal 2017-05-23T15:23:00+00:00 Bjorn Andersson bjorn.andersson@linaro.org 2017-05-09T04:36:37+00:00 efad8396e906d095521791e0408293c101543e50 The SMD channel is not the primary WCNSS channel and must explicitly be closed as the device is removed, or the channel will already by open on a subsequent probe call in e.g. the case of reloading the kernel module. This issue was introduced because I simplified the underlying SMD implementation while the SMD adaptions of the driver sat on the mailing list, but missed to update these patches. The patch does however only apply back to the transition to rpmsg, hence the limited Fixes. Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Reported-by: Eyal Ilsar <c_eilsar@qti.qualcomm.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> 
The SMD channel is not the primary WCNSS channel and must explicitly be
closed as the device is removed, or the channel will already by open on
a subsequent probe call in e.g. the case of reloading the kernel module.

This issue was introduced because I simplified the underlying SMD
implementation while the SMD adaptions of the driver sat on the mailing
list, but missed to update these patches. The patch does however only
apply back to the transition to rpmsg, hence the limited Fixes.

Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg")
Reported-by: Eyal Ilsar <c_eilsar@qti.qualcomm.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
mac80211: properly remove RX_ENC_FLAG_40MHZ 2017-05-08T09:11:56+00:00 Johannes Berg johannes.berg@intel.com 2017-05-05T09:53:19+00:00 2f242bf45370b8ea44f209b22c3c90984655a102 Somehow I missed this in my RX rate cleanup series, causing some drivers to not report correct bandwidth since this flag isn't used by mac80211 anymore. Fix this, and make hwsim also report higher bandwidths appropriately. Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Somehow I missed this in my RX rate cleanup series, causing some
drivers to not report correct bandwidth since this flag isn't
used by mac80211 anymore. Fix this, and make hwsim also report
higher bandwidths appropriately.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: add request id to cfg80211_sched_scan_*() api 2017-04-28T12:51:43+00:00 Arend Van Spriel arend.vanspriel@broadcom.com 2017-04-28T12:40:28+00:00 b34939b9836950d261610132853311054b507247 Have proper request id filled in the SCHED_SCAN_RESULTS and SCHED_SCAN_STOPPED notifications toward user-space by having the driver provide it through the api. Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Have proper request id filled in the SCHED_SCAN_RESULTS and
SCHED_SCAN_STOPPED notifications toward user-space by having the
driver provide it through the api.

Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: unify cfg80211_roamed() and cfg80211_roamed_bss() 2017-04-28T10:28:44+00:00 Avraham Stern avraham.stern@intel.com 2017-04-26T07:58:49+00:00 29ce6ecbb83c9185d76e3a7c340c9702d2a54961 cfg80211_roamed() and cfg80211_roamed_bss() take the same arguments except that cfg80211_roamed() requires the BSSID and cfg80211_roamed_bss() requires the bss entry. Unify the two functions by using a struct for driver initiated roaming information so that either the BSSID or the bss entry can be passed as an argument to the unified function. Signed-off-by: Avraham Stern <avraham.stern@intel.com> [modified the ath6k, brcm80211, rndis and wlan-ng drivers accordingly] Signed-off-by: Luca Coelho <luciano.coelho@intel.com> [modify brcmfmac to remove the useless cast, spotted by Arend] Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
cfg80211_roamed() and cfg80211_roamed_bss() take the same arguments
except that cfg80211_roamed() requires the BSSID and
cfg80211_roamed_bss() requires the bss entry.

Unify the two functions by using a struct for driver initiated
roaming information so that either the BSSID or the bss entry can be
passed as an argument to the unified function.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
[modified the ath6k, brcm80211, rndis and wlan-ng drivers accordingly]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
[modify brcmfmac to remove the useless cast, spotted by Arend]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: rename ieee80211_rx_status::vht_nss to just nss 2017-04-28T08:41:53+00:00 Johannes Berg johannes.berg@intel.com 2017-04-26T11:51:41+00:00 8613c94815fcdd358638a22fed50c3f172042aa2 This field will need to be used again for HE, so rename it now. Again, mostly done with this spatch: @@ expression status; @@ -status->vht_nss +status->nss @@ expression status; @@ -status.vht_nss +status.nss Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
This field will need to be used again for HE, so rename it now.

Again, mostly done with this spatch:

@@
expression status;
@@
-status->vht_nss
+status->nss
@@
expression status;
@@
-status.vht_nss
+status.nss

Signed-off-by: Johannes Berg <johannes.berg@intel.com>