linux-stable.git/net/wireless/scan.c, branch v5.4

cfg80211: fix a bunch of RCU issues in multi-bssid code

2019-10-07T19:35:57+00:00

cfg80211_update_notlisted_nontrans() leaves the RCU critical session
too early, while still using nontrans_ssid which is RCU protected. In
addition, it performs a bunch of RCU pointer update operations such
as rcu_access_pointer and rcu_assign_pointer.

The caller, cfg80211_inform_bss_frame_data(), also accesses the RCU
pointer without holding the lock.

Just wrap all of this with bss_lock.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Link: https://lore.kernel.org/r/20191004123706.15768-3-luca@coelho.fi
Signed-off-by: Johannes Berg

cfg80211: validate SSID/MBSSID element ordering assumption

2019-10-01T15:56:18+00:00

The code copying the data assumes that the SSID element is
before the MBSSID element, but since the data is untrusted
from the AP, this cannot be guaranteed.

Validate that this is indeed the case and ignore the MBSSID
otherwise, to avoid having to deal with both cases for the
copy of data that should be between them.

Cc: stable@vger.kernel.org
Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Link: https://lore.kernel.org/r/1569009255-I1673911f5eae02964e21bdc11b2bf58e5e207e59@changeid
Signed-off-by: Johannes Berg

cfg80211: fix duplicated scan entries after channel switch

2019-07-29T14:23:13+00:00

When associated BSS completes channel switch procedure, its channel
record needs to be updated. The existing mac80211 solution was
extended to cfg80211 in commit 5dc8cdce1d72 ("mac80211/cfg80211:
update bss channel on channel switch").

However that solution still appears to be incomplete as it may lead
to duplicated scan entries for associated BSS after channel switch.
The root cause of the problem is as follows. Each BSS entry is
included into the following data structures:
- bss list rdev->bss_list
- bss search tree rdev->bss_tree
Updating BSS channel record without rebuilding bss_tree may break
tree search since cmp_bss considers all of the following: channel,
bssid, ssid. When BSS channel is updated, but its location in bss_tree
is not updated, then subsequent search operations may fail to locate
this BSS since they will be traversing bss_tree in wrong direction.
As a result, for scan performed after associated BSS channel switch,
cfg80211_bss_update may add the second entry for the same BSS to both
bss_list and bss_tree, rather then update the existing one.

To summarize, if BSS channel needs to be updated, then bss_tree should
be rebuilt in order to put updated BSS entry into a proper location.

This commit suggests the following straightforward solution:
- if new entry has been already created for BSS after channel switch,
  then use its IEs to update known BSS entry and then remove new
  entry completely
- use rb_erase/rb_insert_bss reinstall updated BSS in bss_tree
- for nontransmit BSS entry, the whole transmit BSS hierarchy
  is updated

Signed-off-by: Sergey Matyukevich 
Link: https://lore.kernel.org/r/20190726163922.27509-3-sergey.matyukevich.os@quantenna.com
Signed-off-by: Johannes Berg

cfg80211: refactor cfg80211_bss_update

2019-07-29T14:23:13+00:00

This patch implements minor refactoring for cfg80211_bss_update function.
Code path for updating known BSS is extracted into dedicated
cfg80211_update_known_bss function.

Signed-off-by: Sergey Matyukevich 
Link: https://lore.kernel.org/r/20190726163922.27509-2-sergey.matyukevich.os@quantenna.com
Signed-off-by: Johannes Berg

cfg80211: give all multi-BSSID BSS entries the same timestamp

2019-07-26T11:31:46+00:00

If we just read jiffies over and over again, a non-transmitting
entry may have a newer timestamp than the transmitting one,
leading to possible confusion on expiry. Give them all the same
timestamp when creating them.

Signed-off-by: Johannes Berg 
Reviewed-by: Sergey Matyukevich 
Link: https://lore.kernel.org/r/20190703133823.10530-3-johannes@sipsolutions.net
Signed-off-by: Johannes Berg

cfg80211: don't parse MBSSID if transmitting BSS isn't created

2019-07-26T11:31:30+00:00

Don't parse the multi-BSSID structures if we couldn't even create
their transmitting BSS, this would confuse all of our tracking.

This also means that non_tx_data->tx_bss will never be NULL, so
we can clean up a little bit.

Signed-off-by: Johannes Berg 
Reviewed-by: Sergey Matyukevich 
Link: https://lore.kernel.org/r/20190703133823.10530-2-johannes@sipsolutions.net
Signed-off-by: Johannes Berg

cfg80211: clean up cfg80211_inform_single_bss_frame_data()

2019-07-26T11:31:00+00:00

cfg80211_inform_single_bss_frame_data() doesn't need the
non_tx_data data argument since it's always NULL.

Signed-off-by: Johannes Berg 
Reviewed-by: Sergey Matyukevich 
Link: https://lore.kernel.org/r/20190703133823.10530-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2019-06-18T03:20:36+00:00

Honestly all the conflicts were simple overlapping changes,
nothing really interesting to report.

Signed-off-by: David S. Miller

cfg80211: use BIT_ULL in cfg80211_parse_mbssid_data()

2019-06-14T13:46:33+00:00

The seen_indices variable is u64 and in other parts of the code we
assume mbssid_index_ie[2] can be up to 45, so we should use the 64-bit
versions of BIT, namely, BIT_ULL().

Reported-by: Dan Carpented 
Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg

cfg80211: Add a function to iterate all BSS entries

2019-06-14T12:16:02+00:00

Add a function that iterates over the BSS entries associated with a
given wiphy and calls a callback for each iterated BSS. This can be
used by drivers in various ways, e.g., to evaluate some property for
all the BSSs in the medium.

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