linux-stable.git/net/wireless, branch linux-4.10.y

cfg80211: check rdev resume callback only for registered wiphy

2017-04-12T10:42:05+00:00

commit b3ef5520c1eabb56064474043c7c55a1a65b8708 upstream.

We got the following use-after-free KASAN report:

 BUG: KASAN: use-after-free in wiphy_resume+0x591/0x5a0 [cfg80211]
	 at addr ffff8803fc244090
 Read of size 8 by task kworker/u16:24/2587
 CPU: 6 PID: 2587 Comm: kworker/u16:24 Tainted: G    B 4.9.13-debug+
 Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 1.2.19 12/22/2016
 Workqueue: events_unbound async_run_entry_fn
  ffff880425d4f9d8 ffffffffaeedb541 ffff88042b80ef00 ffff8803fc244088
  ffff880425d4fa00 ffffffffae84d7a1 ffff880425d4fa98 ffff8803fc244080
  ffff88042b80ef00 ffff880425d4fa88 ffffffffae84da3a ffffffffc141f7d9
 Call Trace:
  [] dump_stack+0x85/0xc4
  [] kasan_object_err+0x21/0x70
  [] kasan_report_error+0x1fa/0x500
  [] ? cfg80211_bss_age+0x39/0xc0 [cfg80211]
  [] ? cfg80211_bss_age+0x9a/0xc0 [cfg80211]
  [] ? trace_hardirqs_on+0xd/0x10
  [] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
  [] __asan_report_load8_noabort+0x61/0x70
  [] ? wiphy_suspend+0xbb0/0xc70 [cfg80211]
  [] ? wiphy_resume+0x591/0x5a0 [cfg80211]
  [] wiphy_resume+0x591/0x5a0 [cfg80211]
  [] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
  [] dpm_run_callback+0x6e/0x4f0
  [] device_resume+0x1c2/0x670
  [] async_resume+0x1d/0x50
  [] async_run_entry_fn+0xfe/0x610
  [] process_one_work+0x716/0x1a50
  [] ? process_one_work+0x679/0x1a50
  [] ? _raw_spin_unlock_irq+0x3d/0x60
  [] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
  [] worker_thread+0xe0/0x1460
  [] ? process_one_work+0x1a50/0x1a50
  [] kthread+0x222/0x2e0
  [] ? kthread_park+0x80/0x80
  [] ? kthread_park+0x80/0x80
  [] ? kthread_park+0x80/0x80
  [] ret_from_fork+0x2a/0x40
 Object at ffff8803fc244088, in cache kmalloc-1024 size: 1024
 Allocated:
 PID = 71
  save_stack_trace+0x1b/0x20
  save_stack+0x46/0xd0
  kasan_kmalloc+0xad/0xe0
  kasan_slab_alloc+0x12/0x20
  __kmalloc_track_caller+0x134/0x360
  kmemdup+0x20/0x50
  brcmf_cfg80211_attach+0x10b/0x3a90 [brcmfmac]
  brcmf_bus_start+0x19a/0x9a0 [brcmfmac]
  brcmf_pcie_setup+0x1f1a/0x3680 [brcmfmac]
  brcmf_fw_request_nvram_done+0x44c/0x11b0 [brcmfmac]
  request_firmware_work_func+0x135/0x280
  process_one_work+0x716/0x1a50
  worker_thread+0xe0/0x1460
  kthread+0x222/0x2e0
  ret_from_fork+0x2a/0x40
 Freed:
 PID = 2568
  save_stack_trace+0x1b/0x20
  save_stack+0x46/0xd0
  kasan_slab_free+0x71/0xb0
  kfree+0xe8/0x2e0
  brcmf_cfg80211_detach+0x62/0xf0 [brcmfmac]
  brcmf_detach+0x14a/0x2b0 [brcmfmac]
  brcmf_pcie_remove+0x140/0x5d0 [brcmfmac]
  brcmf_pcie_pm_leave_D3+0x198/0x2e0 [brcmfmac]
  pci_pm_resume+0x186/0x220
  dpm_run_callback+0x6e/0x4f0
  device_resume+0x1c2/0x670
  async_resume+0x1d/0x50
  async_run_entry_fn+0xfe/0x610
  process_one_work+0x716/0x1a50
  worker_thread+0xe0/0x1460
  kthread+0x222/0x2e0
  ret_from_fork+0x2a/0x40
 Memory state around the buggy address:
  ffff8803fc243f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff8803fc244000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 >ffff8803fc244080: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                          ^
  ffff8803fc244100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8803fc244180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

What is happening is that brcmf_pcie_resume() detects a device that
is no longer responsive and it decides to unbind resulting in a
wiphy_unregister() and wiphy_free() call. Now the wiphy instance
remains allocated, because PM needs to call wiphy_resume() for it.
However, brcmfmac already does a kfree() for the struct
cfg80211_registered_device::ops field. Change the checks in
wiphy_resume() to only access the struct cfg80211_registered_device::ops
if the wiphy instance is still registered at this time.

Reported-by: Daniel J Blueman 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

nl80211: fix dumpit error path RTNL deadlocks

2017-03-30T07:44:05+00:00

commit ea90e0dc8cecba6359b481e24d9c37160f6f524f upstream.

Sowmini pointed out Dmitry's RTNL deadlock report to me, and it turns out
to be perfectly accurate - there are various error paths that miss unlock
of the RTNL.

To fix those, change the locking a bit to not be conditional in all those
nl80211_prepare_*_dump() functions, but make those require the RTNL to
start with, and fix the buggy error paths. This also let me use sparse
(by appropriately overriding the rtnl_lock/rtnl_unlock functions) to
validate the changes.

Reported-by: Sowmini Varadhan 
Reported-by: Dmitry Vyukov 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

nl80211: Fix mesh HT operation check

2017-02-06T06:59:07+00:00

A previous change to fix checks for NL80211_MESHCONF_HT_OPMODE
missed setting the flag when replacing FILL_IN_MESH_PARAM_IF_SET
with checking codes. This results in dropping the received HT
operation value when called by nl80211_update_mesh_config(). Fix
this by setting the flag properly.

Fixes: 9757235f451c ("nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value")
Signed-off-by: Masashi Honma 
[rewrite commit message to use Fixes: line]
Signed-off-by: Johannes Berg

cfg80211: consider VHT opmode on station update

2017-01-11T15:34:25+00:00

Currently, this attribute is only fetched on station addition, but
not on station change. Since this info is only present in the assoc
request, with full station state support in the driver it cannot be
present when the station is added.

Thus, add support for changing the VHT opmode on station update if
done before (or while) the station is marked as associated. After
this, ignore it, since it used to be ignored.

Signed-off-by: Beni Lev 
Signed-off-by: Johannes Berg

nl80211: fix sched scan netlink socket owner destruction

2017-01-05T09:59:53+00:00

A single netlink socket might own multiple interfaces *and* a
scheduled scan request (which might belong to another interface),
so when it goes away both may need to be destroyed.

Remove the schedule_scan_stop indirection to fix this - it's only
needed for interface destruction because of the way this works
right now, with a single work taking care of all interfaces.

Cc: stable@vger.kernel.org
Fixes: 93a1e86ce10e4 ("nl80211: Stop scheduled scan if netlink client disappears")
Signed-off-by: Johannes Berg

Makefile: drop -D__CHECK_ENDIAN__ from cflags

2016-12-15T22:13:43+00:00

That's the default now, no need for makefiles to set it.

Signed-off-by: Michael S. Tsirkin 
Acked-by: Kalle Valo 
Acked-by: Marcel Holtmann 
Acked-by: Marc Kleine-Budde 
Acked-by: Greg Kroah-Hartman 
Acked-by: Arend van Spriel

Merge tag 'mac80211-next-for-davem-2016-12-09' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2016-12-10T03:59:05+00:00

Johannes Berg says:

====================
Three fixes:
 * fix a logic bug introduced by a previous cleanup
 * fix nl80211 attribute confusing (trying to use
   a single attribute for two purposes)
 * fix a long-standing BSS leak that happens when an
   association attempt is abandoned
====================

Signed-off-by: David S. Miller

cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts

2016-12-09T11:57:49+00:00

When mac80211 abandons an association attempt, it may free
all the data structures, but inform cfg80211 and userspace
about it only by sending the deauth frame it received, in
which case cfg80211 has no link to the BSS struct that was
used and will not cfg80211_unhold_bss() it.

Fix this by providing a way to inform cfg80211 of this with
the BSS entry passed, so that it can clean up properly, and
use this ability in the appropriate places in mac80211.

This isn't ideal: some code is more or less duplicated and
tracing is missing. However, it's a fairly small change and
it's thus easier to backport - cleanups can come later.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg

nl80211: Use different attrs for BSSID and random MAC addr in scan req

2016-12-09T11:47:19+00:00

NL80211_ATTR_MAC was used to set both the specific BSSID to be scanned
and the random MAC address to be used when privacy is enabled. When both
the features are enabled, both the BSSID and the local MAC address were
getting same value causing Probe Request frames to go with unintended
DA. Hence, this has been fixed by using a different NL80211_ATTR_BSSID
attribute to set the specific BSSID (which was the more recent addition
in cfg80211) for a scan.

Backwards compatibility with old userspace software is maintained to
some extent by allowing NL80211_ATTR_MAC to be used to set the specific
BSSID when scanning without enabling random MAC address use.

Scanning with random source MAC address was introduced by commit
ad2b26abc157 ("cfg80211: allow drivers to support random MAC addresses
for scan") and the issue was introduced with the addition of the second
user for the same attribute in commit 818965d39177 ("cfg80211: Allow a
scan request for a specific BSSID").

Fixes: 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID")
Signed-off-by: Vamsi Krishna 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg

nl80211: fix logic inversion in start_nan()

2016-12-09T11:47:18+00:00

Arend inadvertently inverted the logic while converting to
wdev_running(), fix that.

Fixes: 73c7da3dae1e ("cfg80211: add generic helper to check interface is running")
Signed-off-by: Johannes Berg