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

cfg80211: Check if NAN service ID is of expected size

2017-07-21T05:00:10+00:00

commit 0a27844ce86d039d74221dd56cd8c0349b146b63 upstream.

nla policy checks for only maximum length of the attribute data when the
attribute type is NLA_BINARY. If userspace sends less data than
specified, cfg80211 may access illegal memory. When type is NLA_UNSPEC,
nla policy check ensures that userspace sends minimum specified length
number of bytes.

Remove type assignment to NLA_BINARY from nla_policy of
NL80211_NAN_FUNC_SERVICE_ID to make these NLA_UNSPEC and to make sure
minimum NL80211_NAN_FUNC_SERVICE_ID_LEN bytes are received from
userspace with NL80211_NAN_FUNC_SERVICE_ID.

Fixes: a442b761b24 ("cfg80211: add add_nan_func / del_nan_func")
Signed-off-by: Srinivas Dasari 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: Check if PMKID attribute is of expected size

2017-07-21T05:00:10+00:00

commit 9361df14d1cbf966409d5d6f48bb334384fbe138 upstream.

nla policy checks for only maximum length of the attribute data
when the attribute type is NLA_BINARY. If userspace sends less
data than specified, the wireless drivers may access illegal
memory. When type is NLA_UNSPEC, nla policy check ensures that
userspace sends minimum specified length number of bytes.

Remove type assignment to NLA_BINARY from nla_policy of
NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum
WLAN_PMKID_LEN bytes are received from userspace with
NL80211_ATTR_PMKID.

Fixes: 67fbb16be69d ("nl80211: PMKSA caching support")
Signed-off-by: Srinivas Dasari 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES

2017-07-21T05:00:10+00:00

commit d7f13f7450369281a5d0ea463cc69890a15923ae upstream.

validate_scan_freqs() retrieves frequencies from attributes
nested in the attribute NL80211_ATTR_SCAN_FREQUENCIES with
nla_get_u32(), which reads 4 bytes from each attribute
without validating the size of data received. Attributes
nested in NL80211_ATTR_SCAN_FREQUENCIES don't have an nla policy.

Validate size of each attribute before parsing to avoid potential buffer
overread.

Fixes: 2a519311926 ("cfg80211/nl80211: scanning (and mac80211 update to use it)")
Signed-off-by: Srinivas Dasari 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE

2017-07-21T05:00:09+00:00

commit 8feb69c7bd89513be80eb19198d48f154b254021 upstream.

Buffer overread may happen as nl80211_set_station() reads 4 bytes
from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without
validating the size of data received when userspace sends less
than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE.
Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid
the buffer overread.

Fixes: 3b1c5a5307f ("{cfg,nl}80211: mesh power mode primitives and userspace access")
Signed-off-by: Srinivas Dasari 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: strictly check mesh address extension mode

2017-06-24T05:06:15+00:00

commit 5667c86acf021e6dcf02584408b4484a273ac68f upstream.

Mesh forwarding path checks for address extension mode to fetch
appropriate proxied address and MPP address. Existing condition
that looks for 6 address format is not strict enough so that
frames with improper values are processed and invalid entries
are added into MPP table. Fix that by adding a stricter check before
processing the packet.

Per IEEE Std 802.11s-2011 spec. Table 7-6g1 lists address extension
mode 0x3 as reserved one. And also Table Table 9-13 does not specify
0x3 as valid address field.

Fixes: 9b395bc3be1c ("mac80211: verify that skb data is present")
Signed-off-by: Rajkumar Manoharan 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: check rdev resume callback only for registered wiphy

2017-03-29T07:11:29+00:00

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.

Cc: stable@vger.kernel.org # 4.10.x, 4.9.x
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

nl80211: fix dumpit error path RTNL deadlocks

2017-03-16T09:30:03+00:00

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.

Cc: stable@vger.kernel.org
Reported-by: Sowmini Varadhan 
Reported-by: Dmitry Vyukov 
Signed-off-by: Johannes Berg

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

2017-02-10T19:31:51+00:00

Johannes Berg says:

====================
Some more updates:
 * use shash in mac80211 crypto code where applicable
 * some documentation fixes
 * pass RSSI levels up in change notifications
 * remove unused rfkill-regulator
 * various other cleanups
====================

Signed-off-by: David S. Miller

cfg80211: fix NAN bands definition

2017-02-09T14:17:30+00:00

The nl80211_nan_dual_band_conf enumeration doesn't make much sense.
The default value is assigned to a bit, which makes it weird if the
default bit and other bits are set at the same time.

To improve this, get rid of NL80211_NAN_BAND_DEFAULT and add a wiphy
configuration to let the drivers define which bands are supported.
This is exposed to the userspace, which then can make a decision on
which band(s) to use.  Additionally, rename all "dual_band" elements
to "bands", to make things clearer.

Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg

cfg80211: Pass new RSSI level in CQM RSSI notification

2017-02-08T09:43:40+00:00

Update the drivers to pass the RSSI level as a cfg80211_cqm_rssi_notify
parameter and pass this value to userspace in a new nl80211 attribute.
This helps both userspace and also helps in the implementation of the
multiple RSSI thresholds CQM mechanism.

Note for marvell/mwifiex I pass 0 for the RSSI value because the new
RSSI value is not available to the driver at the time of the
cfg80211_cqm_rssi_notify call, but the driver queries the new value
immediately after that, so it is actually available just a moment later
if we wanted to defer caling cfg80211_cqm_rssi_notify until that moment.
Without this, the new cfg80211 code (patch 3) will call .get_station
which will send a duplicate HostCmd_CMD_RSSI_INFO command to the hardware.

Signed-off-by: Andrew Zaborowski 
Signed-off-by: Johannes Berg