linux-stable.git/net/wireless, branch v4.9.166

cfg80211: extend range deviation for DMG

2019-03-05T16:57:06+00:00

[ Upstream commit 93183bdbe73bbdd03e9566c8dc37c9d06b0d0db6 ]

Recently, DMG frequency bands have been extended till 71GHz, so extend
the range check till 20GHz (45-71GHZ), else some channels will be marked
as disabled.

Signed-off-by: Chaitanya Tata 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

nl80211: Fix possible Spectre-v1 for NL80211_TXRATE_HT

2018-11-10T15:42:42+00:00

[ Upstream commit 30fe6d50eb088783c8729c7d930f65296b2b3fa7 ]

Use array_index_nospec() to sanitize ridx with respect to speculation.

Signed-off-by: Masashi Honma 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

cfg80211: Address some corner cases in scan result channel updating

2018-11-10T15:42:41+00:00

[ Upstream commit 119f94a6fefcc76d47075b83d2b73d04c895df78 ]

cfg80211_get_bss_channel() is used to update the RX channel based on the
available frame payload information (channel number from DSSS Parameter
Set element or HT Operation element). This is needed on 2.4 GHz channels
where frames may be received on neighboring channels due to overlapping
frequency range.

This might of some use on the 5 GHz band in some corner cases, but
things are more complex there since there is no n:1 or 1:n mapping
between channel numbers and frequencies due to multiple different
starting frequencies in different operating classes. This could result
in ieee80211_channel_to_frequency() returning incorrect frequency and
ieee80211_get_channel() returning incorrect channel information (or
indication of no match). In the previous implementation, this could
result in some scan results being dropped completely, e.g., for the 4.9
GHz channels. That prevented connection to such BSSs.

Fix this by using the driver-provided channel pointer if
ieee80211_get_channel() does not find matching channel data for the
channel number in the frame payload and if the scan is done with 5 MHz
or 10 MHz channel bandwidth. While doing this, also add comments
describing what the function is trying to achieve to make it easier to
understand what happens here and why.

Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

cfg80211: reg: Init wiphy_idx in regulatory_hint_core()

2018-11-10T15:42:41+00:00

[ Upstream commit 24f33e64fcd0d50a4b1a8e5b41bd0257aa66b0e8 ]

Core regulatory hints didn't set wiphy_idx to WIPHY_IDX_INVALID. Since
the regulatory request is zeroed, wiphy_idx was always implicitly set to
0. This resulted in updating only phy #0.
Fix that.

Fixes: 806a9e39670b ("cfg80211: make regulatory_request use wiphy_idx instead of wiphy")
Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
[add fixes tag]
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

cfg80211: fix a type issue in ieee80211_chandef_to_operating_class()

2018-10-10T06:53:19+00:00

[ Upstream commit 8442938c3a2177ba16043b3a935f2c78266ad399 ]

The "chandef->center_freq1" variable is a u32 but "freq" is a u16 so we
are truncating away the high bits.  I noticed this bug because in commit
9cf0a0b4b64a ("cfg80211: Add support for 60GHz band channels 5 and 6")
we made "freq <= 56160 + 2160 * 6" a valid requency when before it was
only "freq <= 56160 + 2160 * 4" that was valid.  It introduces a static
checker warning:

    net/wireless/util.c:1571 ieee80211_chandef_to_operating_class()
    warn: always true condition '(freq <= 56160 + 2160 * 6) => (0-u16max <= 69120)'

But really we probably shouldn't have been truncating the high bits
away to begin with.

Signed-off-by: Dan Carpenter 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cfg80211: nl80211_update_ft_ies() to validate NL80211_ATTR_IE

2018-10-10T06:53:18+00:00

[ Upstream commit 4f0223bfe9c3e62d8f45a85f1ef1b18a8a263ef9 ]

nl80211_update_ft_ies() tried to validate NL80211_ATTR_IE with
is_valid_ie_attr() before dereferencing it, but that helper function
returns true in case of NULL pointer (i.e., attribute not included).
This can result to dereferencing a NULL pointer. Fix that by explicitly
checking that NL80211_ATTR_IE is included.

Fixes: 355199e02b83 ("cfg80211: Extend support for IEEE 802.11r Fast BSS Transition")
Signed-off-by: Arunk Khandavalli 
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nl80211: fix null-ptr dereference on invalid mesh configuration

2018-09-19T20:47:11+00:00

commit 265698d7e6132a2d41471135534f4f36ad15b09c upstream.

If TX rates are specified during mesh join, the channel must
also be specified. Check the channel pointer to avoid a null
pointer dereference if it isn't.

Reported-by: Jouni Malinen 
Fixes: 8564e38206de ("cfg80211: add checks for beacon rate, extend to mesh")
Signed-off-by: Johannes Berg 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

nl80211: Add a missing break in parse_station_flags

2018-09-05T07:19:59+00:00

[ Upstream commit 5cf3006cc81d9aa09a10aa781fc065546b12919d ]

I was looking at usually suppressed gcc warnings,
[-Wimplicit-fallthrough=] in this case:

The code definitely looks like a break is missing here.
However I am not able to test the NL80211_IFTYPE_MESH_POINT,
nor do I actually know what might be :)
So please use this patch with caution and only if you are
able to do some testing.

Signed-off-by: Bernd Edlinger 
[johannes: looks obvious enough to apply as is, interesting
 though that it never seems to have been a problem]
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nl80211: relax ht operation checks for mesh

2018-08-24T11:12:33+00:00

[ Upstream commit 188f60ab8e787fcbb5ac9d64ede23a0070231f09 ]

Commit 9757235f451c, "nl80211: correct checks for
NL80211_MESHCONF_HT_OPMODE value") relaxed the range for the HT
operation field in meshconf, while also adding checks requiring
the non-greenfield and non-ht-sta bits to be set in certain
circumstances.  The latter bit is actually reserved for mesh BSSes
according to Table 9-168 in 802.11-2016, so in fact it should not
be set.

wpa_supplicant sets these bits because the mesh and AP code share
the same implementation, but authsae does not.  As a result, some
meshconf updates from authsae which set only the NONHT_MIXED
protection bits were being rejected.

In order to avoid breaking userspace by changing the rules again,
simply accept the values with or without the bits set, and mask
off the reserved bit to match the spec.

While in here, update the 802.11-2012 reference to 802.11-2016.

Fixes: 9757235f451c ("nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value")
Cc: Masashi Honma 
Signed-off-by: Bob Copeland 
Reviewed-by: Masashi Honma 
Reviewed-by: Masashi Honma 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cfg80211: limit wiphy names to 128 bytes

2018-05-25T14:12:59+00:00

commit a7cfebcb7594a24609268f91299ab85ba064bf82 upstream.

There's currently no limit on wiphy names, other than netlink
message size and memory limitations, but that causes issues when,
for example, the wiphy name is used in a uevent, e.g. in rfkill
where we use the same name for the rfkill instance, and then the
buffer there is "only" 2k for the environment variables.

This was reported by syzkaller, which used a 4k name.

Limit the name to something reasonable, I randomly picked 128.

Reported-by: syzbot+230d9e642a85d3fec29c@syzkaller.appspotmail.com
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman