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

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

net: Fix inconsistent teardown and release of private netdev state.

2017-06-07T19:53:24+00:00

Network devices can allocate reasources and private memory using
netdev_ops->ndo_init().  However, the release of these resources
can occur in one of two different places.

Either netdev_ops->ndo_uninit() or netdev->destructor().

The decision of which operation frees the resources depends upon
whether it is necessary for all netdev refs to be released before it
is safe to perform the freeing.

netdev_ops->ndo_uninit() presumably can occur right after the
NETDEV_UNREGISTER notifier completes and the unicast and multicast
address lists are flushed.

netdev->destructor(), on the other hand, does not run until the
netdev references all go away.

Further complicating the situation is that netdev->destructor()
almost universally does also a free_netdev().

This creates a problem for the logic in register_netdevice().
Because all callers of register_netdevice() manage the freeing
of the netdev, and invoke free_netdev(dev) if register_netdevice()
fails.

If netdev_ops->ndo_init() succeeds, but something else fails inside
of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
it is not able to invoke netdev->destructor().

This is because netdev->destructor() will do a free_netdev() and
then the caller of register_netdevice() will do the same.

However, this means that the resources that would normally be released
by netdev->destructor() will not be.

Over the years drivers have added local hacks to deal with this, by
invoking their destructor parts by hand when register_netdevice()
fails.

Many drivers do not try to deal with this, and instead we have leaks.

Let's close this hole by formalizing the distinction between what
private things need to be freed up by netdev->destructor() and whether
the driver needs unregister_netdevice() to perform the free_netdev().

netdev->priv_destructor() performs all actions to free up the private
resources that used to be freed by netdev->destructor(), except for
free_netdev().

netdev->needs_free_netdev is a boolean that indicates whether
free_netdev() should be done at the end of unregister_netdevice().

Now, register_netdevice() can sanely release all resources after
ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
and netdev->priv_destructor().

And at the end of unregister_netdevice(), we invoke
netdev->priv_destructor() and optionally call free_netdev().

Signed-off-by: David S. Miller