BMC/Intel-BMC/linux.git/net/wireless, branch dev-5.1

nl80211: fix station_info pertid memory leak

2019-06-25T03:34:56+00:00

commit f77bf4863dc2218362f4227d56af4a5f3f08830c upstream. When dumping stations, memory allocated for station_info's pertid member will leak if the nl80211 header cannot be added to the sk_buff due to insufficient tail room. I noticed this leak in the kmalloc-2048 cache. Cc: stable@vger.kernel.org Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station info") Signed-off-by: Andy Strohman Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

{nl,mac}80211: allow 4addr AP operation on crypto controlled devices

2019-06-25T03:34:55+00:00

commit 33d915d9e8ce811d8958915ccd18d71a66c7c495 upstream. As per the current design, in the case of sw crypto controlled devices, it is the device which advertises the support for AP/VLAN iftype based on it's ability to tranmsit packets encrypted in software (In VLAN functionality, group traffic generated for a specific VLAN group is always encrypted in software). Commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices") has introduced this change. Since 4addr AP operation also uses AP/VLAN iftype, this conditional way of advertising AP/VLAN support has broken 4addr AP mode operation on crypto controlled devices which do not support VLAN functionality. In the case of ath10k driver, not all firmwares have support for VLAN functionality but all can support 4addr AP operation. Because AP/VLAN support is not advertised for these devices, 4addr AP operations are also blocked. Fix this by allowing 4addr operation on devices which do not support AP/VLAN iftype but can support 4addr AP operation (decision is based on the wiphy flag WIPHY_FLAG_4ADDR_AP). Cc: stable@vger.kernel.org Fixes: db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices") Signed-off-by: Manikanta Pubbisetty Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

cfg80211: fix memory leak of wiphy device name

2019-06-25T03:34:55+00:00

commit 4f488fbca2a86cc7714a128952eead92cac279ab upstream. In wiphy_new_nm(), if an error occurs after dev_set_name() and device_initialize() have already been called, it's necessary to call put_device() (via wiphy_free()) to avoid a memory leak. Reported-by: syzbot+7fddca22578bc67c3fe4@syzkaller.appspotmail.com Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211/cfg80211: update bss channel on channel switch

2019-05-31T13:43:22+00:00

[ Upstream commit 5dc8cdce1d722c733f8c7af14c5fb595cfedbfa8 ] FullMAC STAs have no way to update bss channel after CSA channel switch completion. As a result, user-space tools may provide inconsistent channel info. For instance, consider the following two commands: $ sudo iw dev wlan0 link $ sudo iw dev wlan0 info The latter command gets channel info from the hardware, so most probably its output will be correct. However the former command gets channel info from scan cache, so its output will contain outdated channel info. In fact, current bss channel info will not be updated until the next [re-]connect. Note that mac80211 STAs have a workaround for this, but it requires access to internal cfg80211 data, see ieee80211_chswitch_work: /* XXX: shouldn't really modify cfg80211-owned data! */ ifmgd->associated->channel = sdata->csa_chandef.chan; This patch suggests to convert mac80211 workaround into cfg80211 behavior and to update current bss channel in cfg80211_ch_switch_notify. Signed-off-by: Sergey Matyukevich Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

cfg80211: Notify previous user request during self managed wiphy registration

2019-04-23T11:45:30+00:00

Commit c82c06ce43d3("cfg80211: Notify all User Hints To self managed wiphys") notified all new user hints to self managed wiphy's after device registration. But it didn't do this for anything other than cell base hints done before registration. This needs to be done during wiphy registration of a self managed device also, so that the previous user settings are retained. Fixes: c82c06ce43d3 ("cfg80211: Notify all User Hints To self managed wiphys") Signed-off-by: Sriram R Signed-off-by: Johannes Berg

nl80211: Add NL80211_FLAG_CLEAR_SKB flag for other NL commands

2019-03-29T10:23:09+00:00

This commit adds NL80211_FLAG_CLEAR_SKB flag to other NL commands that carry key data to ensure they do not stick around on heap after the SKB is freed. Also introduced this flag for NL80211_CMD_VENDOR as there are sub commands which configure the keys. Signed-off-by: Sunil Dutt Signed-off-by: Johannes Berg

cfg80211: Use kmemdup in cfg80211_gen_new_ie()

2019-03-29T10:22:55+00:00

Use kmemdup rather than duplicating its implementation Signed-off-by: YueHaibing Signed-off-by: Johannes Berg

cfg80211: Change an 'else if' into an 'else' in cfg80211_calculate_bitrate_he

2019-03-29T10:22:23+00:00

When building with -Wsometimes-uninitialized, Clang warns: net/wireless/util.c:1223:11: warning: variable 'result' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] Clang can't evaluate at this point that WARN(1, ...) always returns true because __ret_warn_on is defined as !!(condition), which isn't immediately evaluated as 1. Change this branch to else so that it's clear to Clang that we intend to bail out here. Link: https://github.com/ClangBuiltLinux/linux/issues/382 Suggested-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Reviewed-by: Arnd Bergmann Signed-off-by: Johannes Berg

cfg80211: Handle WMM rules in regulatory domain intersection

2019-03-29T10:20:58+00:00

The support added for regulatory WMM rules did not handle the case of regulatory domain intersections. Fix it. Signed-off-by: Ilan Peer Fixes: 230ebaa189af ("cfg80211: read wmm rules from regulatory database") Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg

Merge remote-tracking branch 'net-next/master' into mac80211-next

2019-02-22T12:48:13+00:00

Merge net-next to resolve a conflict and to get the mac80211 rhashtable fixes so further patches can be applied on top. Signed-off-by: Johannes Berg