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

brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice

2017-08-11T15:33:50+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

brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain

2017-07-21T04:59:06+00:00

commit 5ea59db8a375216e6c915c5586f556766673b5a7 upstream.

An earlier change to this function (3bdae810721b) fixed a leak in the
case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
glom_skb buffer, used for emulating a scattering read, is never used
or referenced after its contents are copied into the destination
buffers, and therefore always needs to be freed by the end of the
function.

Fixes: 3bdae810721b ("brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain")
Fixes: a413e39a38573 ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg support")
Signed-off-by: Peter S. Housel 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: Fix a memory leak in error handling path in 'brcmf_cfg80211_attach'

2017-07-21T04:59:06+00:00

commit 57c00f2fac512837f8de73474ec1f54020015bae upstream.

If 'wiphy_new()' fails, we leak 'ops'. Add a new label in the error
handling path to free it in such a case.

Fixes: 5c22fb85102a7 ("brcmfmac: add wowl gtk rekeying offload support")
Signed-off-by: Christophe JAILLET 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()

2017-07-21T04:59:06+00:00

[ Upstream commit 8f44c9a41386729fea410e688959ddaa9d51be7c ]

The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280.  However, the action_frame->data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.

	memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
	       le16_to_cpu(action_frame->len));

Cc: stable@vger.kernel.org # 3.9.x
Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
Reported-by: "freenerguo(郭大兴)" 
Signed-off-by: Arend van Spriel 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'wireless-drivers-for-davem-2017-06-20' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2017-06-20T19:41:56+00:00

Kalle Valo says:

====================
wireless-drivers fixes for 4.12

Two important fixes for brcmfmac. The rest of the brcmfmac patches are
either code preparation and fixing a new build warning.

brcmfmac

* fix a NULL pointer dereference during resume

* fix a NULL pointer dereference with USB devices, a regression from
  v4.12-rc1
====================

Signed-off-by: David S. Miller

brcmfmac: fix uninitialized warning in brcmf_usb_probe_phase2()

2017-06-16T08:52:36+00:00

This fixes the following warning:

  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function
  'brcmf_usb_probe_phase2':
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1198:2:
  warning: 'devinfo' may be used uninitialized in this function
  [-Wmaybe-uninitialized]
    mutex_unlock(&devinfo->dev_init_lock);

Fixes: 6d0507a777fb ("brcmfmac: add parameter to pass error code in firmware callback")
Cc: Stephen Rothwell 
Reported-by: Kalle Valo 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: fix brcmf_fws_add_interface() for USB devices

2017-06-15T16:10:11+00:00

USB devices rely on queuing functionality provided by the fwsignal
module regardless the mode fwsignal is operating in. For this some
data structure needs to be reserved which is tied to the interface,
which is done by brcmf_fws_add_interface(). However, it checks the
mode. Replace that by checking result from brcmf_fws_queue_skbs().
Otherwise the driver will crash in a null pointer dereference when
data is transmitted on the interface.

Fixes: fc0471e3e884 ("brcmfmac: ignore interfaces when fwsignal is disabled")
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: unbind all devices upon failure in firmware callback

2017-06-15T16:06:53+00:00

When request firmware fails, brcmf_ops_sdio_remove is being called and
brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
the kernel hangs on resume due a NULL pointer dereference in resume
function. So in brcmf_sdio_firmware_callback() we need to unbind the
driver from both sdio_func devices when firmware load failure is indicated.

Cc: stable@vger.kernel.org # 4.9.x-
Tested-by: Enric Balletbo i Serra 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: use firmware callback upon failure to load

2017-06-15T16:06:11+00:00

When firmware loading failed the code used to unbind the device provided
by the calling code. However, for the sdio driver two devices are bound
and both need to be released upon failure. The callback has been extended
with parameter to pass error code so add that in this commit upon firmware
loading failure.

Cc: stable@vger.kernel.org # 4.9.x-
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: add parameter to pass error code in firmware callback

2017-06-15T16:06:00+00:00

Extend the parameters in the firmware callback so it can be called
upon success and failure. This allows the caller to properly clear
all resources in the failure path. Right now the error code is
always zero, ie. success.

Cc: stable@vger.kernel.org # 4.9.x-
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo