linux-stable.git/drivers/net/wireless/broadcom, branch v4.9.78

brcmfmac: change driver unbind order of the sdio function devices

2017-12-14T08:28:13+00:00

commit 5c3de777bdaf48bd0cfb43097c0d0fb85056cab7 upstream.

In the function brcmf_sdio_firmware_callback() the driver is
unbound from the sdio function devices in the error path.
However, the order in which it is done resulted in a use-after-free
issue (see brcmf_ops_sdio_remove() in bcmsdh.c). Hence change
the order and first unbind sdio function #2 device and then
unbind sdio function #1 device.

Fixes: 7a51461fc2da ("brcmfmac: unbind all devices upon failure in firmware callback")
Reported-by: Stefan Wahren 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: don't preset all channels as disabled

2017-11-21T08:23:30+00:00

commit 9ea0c307609fd20e03f53546b9cefbb20b96785d upstream.

During init we take care of regulatory stuff by disabling all
unavailable channels (see brcmf_construct_chaninfo) so this predisabling
them is not really required (and this patch won't change any behavior).
It will on the other hand allow more detailed runtime control over
channels which is the main reason for this change.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo 
Cc: Lambdadroid 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: remove setting IBSS mode when stopping AP

2017-11-18T10:22:24+00:00

commit 9029679f66d976f8c720eb03c4898274803c9923 upstream.

Upon stopping an AP interface the driver disable INFRA mode effectively
setting the interface in IBSS mode. However, this may affect other
interfaces running in INFRA mode. For instance, if user creates and stops
hostap daemon on virtual interface, then association cannot work on
primary interface because default BSS has been set to IBSS mode in
firmware side. The IBSS mode should be set when cfg80211 changes the
interface.

Reviewed-by: Wright Feng 
Signed-off-by: Chi-hsien Lin 
[kvalo@codeaurora.org: rephased commit log based on discussion]
Signed-off-by: Wright Feng 
Signed-off-by: Kalle Valo 
Cc: Philipp Rosenberger 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: setup wiphy bands after registering it first

2017-11-15T14:53:15+00:00

[ Upstream commit ab99063f873749b3c3b1e5d44038559883465e74 ]

During bands setup we disable all channels that firmware doesn't support
in the current regulatory setup. If we do this before wiphy_register
it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
to the orig_flags which is supposed to be persistent. We don't want this
as regulatory change may result in enabling some channels. We shouldn't
mess with orig_flags then (by changing them or ignoring them) so it's
better to just take care of their proper values.

This patch cleanups code a bit (by taking orig_flags more seriously) and
allows further improvements like disabling really unavailable channels.
We will need that e.g. if some frequencies should be disabled for good
due to hardware setup (design).

Signed-off-by: Rafał Miłecki 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: check brcmf_bus_get_memdump result for error

2017-11-08T09:08:36+00:00

[ Upstream commit f4737a62033d7f3e0db740c449fc62119da7ab8a ]

This method may be unsupported (see: USB bus) or may just fail (see:
SDIO bus).
While at it rework logic in brcmf_sdio_bus_get_memdump function to avoid
too many conditional code nesting levels.

Signed-off-by: Rafał Miłecki 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

brcmsmac: make some local variables 'static const' to reduce stack size

2017-10-27T08:38:07+00:00

commit c503dd38f850be28867ef7a42d9abe5ade81a9bd upstream.

With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:

broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.

This is the first of three patches to improve the stack usage in this
driver. It would be good to have this backported to stabl kernels
to get all drivers in 'allmodconfig' below the 2048 byte limit so
we can turn on the frame warning again globally, but I realize that
the patch is larger than the normal limit for stable backports.

The other two patches do not need to be backported.

Acked-by: Arend van Spriel 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: Add check for short event packets

2017-10-27T08:38:07+00:00

commit dd2349121bb1b8ff688c3ca6a2a0bea9d8c142ca upstream.

The length of the data in the received skb is currently passed into
brcmf_fweh_process_event() as packet_len, but this value is not checked.
event_packet should be followed by DATALEN bytes of additional event
data.  Ensure that the received packet actually contains at least
DATALEN bytes of additional data, to avoid copying uninitialized memory
into event->data.

Suggested-by: Mattias Nissler 
Signed-off-by: Kevin Cernekee 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: setup passive scan if requested by user-space

2017-10-12T09:51:25+00:00

commit 35f62727df0ed8e5e4857e162d94fd46d861f1cf upstream.

The driver was not properly configuring firmware with regard to the
type of scan. It always performed an active scan even when user-space
was requesting for passive scan, ie. the scan request was done without
any SSIDs specified.

Reported-by: Huang, Jiangyang 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: add length check in brcmf_cfg80211_escan_handler()

2017-10-12T09:51:25+00:00

commit 17df6453d4be17910456e99c5a85025aa1b7a246 upstream.

Upon handling the firmware notification for scans the length was
checked properly and may result in corrupting kernel heap memory
due to buffer overruns. This fix addresses CVE-2017-0786.

Cc: Kevin Cernekee 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice

2017-08-11T15:49:28+00:00

commit 5f5d03143de5e0c593da4ab18fc6393c2815e108 upstream.

Due to a bugfix in wireless tree and the commit mentioned below a merge
was needed which went haywire. So the submitted change resulted in the
function brcmf_sdiod_sgtable_alloc() being called twice during the probe
thus leaking the memory of the first call.

Fixes: 4d7928959832 ("brcmfmac: switch to new platform data")
Reported-by: Stefan Wahren 
Tested-by: Stefan Wahren 
Reviewed-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman