talos-obmc-linux/drivers/net/wireless/broadcom, branch dev-4.13

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

2017-10-27T08:39:14+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:39:13+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:56:18+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:56:18+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: feature check for multi-scheduled scan fails on bcm4345 devices

2017-09-13T21:20:53+00:00

commit f957dd3c8db2781c8a334b166800788feb618625 upstream. The firmware feature check introduced for multi-scheduled scan is also failing for bcm4345 devices resulting in a firmware crash. The reason for this crash has not yet been root cause so this patch avoids the feature check for those device as a short-term fix. Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature") Signed-off-by: Ian W MORRISON Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

brcmfmac: feature check for multi-scheduled scan fails on bcm4343x devices

2017-08-14T08:09:30+00:00

The firmware feature check introduced for multi-scheduled scan turned out to be failing for bcm4343{0,1,8} devices resulting in a firmware crash. The reason for this crash has not yet been root cause so this patch avoids the feature check for those device as a short-term fix. Reported-by: Stefan Wahren Reported-by: Ian Molton Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature") Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice

2017-07-27T11:03:14+00:00

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. Cc: stable@vger.kernel.org # 4.6.x 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

brcmfmac: Don't grow SKB by negative size

2017-07-27T11:02:16+00:00

The commit to rework the headroom check in start_xmit() now calls pxskb_expand_head() unconditionally if the header is CoW. Unfortunately, it does so with the delta between the extant headroom and the header length, which may be negative if there is already sufficient headroom. pskb_expand_head() does allow for size being 0, in which case it just copies, so clamp the header delta to zero. Opening Chrome (and all my tabs) on a PCIE device was enough to reliably hit this. Fixes: 270a6c1f65fe ("brcmfmac: rework headroom check in .start_xmit()") Signed-off-by: Daniel Stone Cc: Arend Van Spriel Cc: James Hughes Cc: Hante Meuleman Cc: Pieter-Paul Giesberts Cc: Franky Lin Tested-by: Hans de Goede Signed-off-by: Kalle Valo

brcmfmac: fix regression in brcmf_sdio_txpkt_hdalign()

2017-07-21T07:40:48+00:00

Recent change in brcmf_sdio_txpkt_hdalign() changed the behavior and now always returns 0. This resulted in a regression which basically renders the device useless. Fixes: 270a6c1f65fe ("brcmfmac: rework headroom check in .start_xmit()") Reported-by: S. Gilles Tested-by: S. Gilles Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()

2017-07-12T15:29:56+00:00

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