Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read

2017-09-12 Thread Kalle Valo 
Greg KH  writes:

> On Tue, Sep 12, 2017 at 10:18:00AM +0200, Arend van Spriel wrote:
>> + Greg KH
>> 
>> On 9/12/2017 10:05 AM, Kalle Valo wrote:
>> > Arend van Spriel  writes:
>> > 
>> > > It is actually in the stable-kernel-rules documentation [1]:
>> > > 
>> > > """
>> > > Also, some patches may have kernel version prerequisites.  This can be
>> > > specified in the following format in the sign-off area:
>> > > 
>> > > .. code-block:: none
>> > > 
>> > >   Cc:  # 3.3.x
>> > > 
>> > > The tag has the meaning of:
>> > > 
>> > > .. code-block:: none
>> > > 
>> > >   git cherry-pick 
>> > > 
>> > > For each "-stable" tree starting with the specified version.
>> > > """
>> > 
>> > Yeah, but it says "starting with" which I interpret as "starting with
>> > string '3.3'". For example the commit here would be applied to 3.3.1,
>> > 3.3.2 and 3.3.3 etc but _not_ to 3.4, 3.4.1, 3.5 or any later release.
>> > 
>> > Of course I can be way off here, wouldn't be the first :)
>> 
>> Dito. I interpret "each -stable tree" as each stable branch in the stable
>> repository. Would Greg know?
>
> "# 3.8+" and "# 3.8" mean the same thing to me, we would never backport
> something to only a very specific kernel version, and leave newer kernel
> versions to not have that fix.  That would be crazy, and would break our
> "no regressions" rule (i.e. newer kernels should always work as good as
> older kernels.)

Indeed, that would be crazy. Didn't think it like that, thanks for the
clarification.

> Don't get hung up on the semantics here people, it's not all that
> complicated, and I do it all by hand anyway :)

Manually? Oh man, that has to be so hard. I cannot understand how you
can do it.

-- 
Kalle Valo

[PATCH] nl80211: check for the required netlink attributes presence

2017-09-12 Thread Vladis Dronov 
nl80211_set_rekey_data() does not check if the required attributes
NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
users with CAP_NET_ADMIN privilege and may result in NULL dereference
and a system crash. Add a check for the required attributes presence.
This patch is based on the patch by bo Zhang.

This fixes CVE-2017-12153.

References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046
Fixes: e5497d766ad ("cfg80211/nl80211: support GTK rekey offload")
Cc:  # v3.1-rc1
Reported-by: bo Zhang 
Signed-off-by: Vladis Dronov 
---
 net/wireless/nl80211.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 0df8023..fbd5593 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10903,6 +10903,9 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, 
struct genl_info *info)
if (err)
return err;
 
+   if (!tb[NL80211_REKEY_DATA_REPLAY_CTR] || !tb[NL80211_REKEY_DATA_KEK] ||
+   !tb[NL80211_REKEY_DATA_KCK])
+   return -EINVAL;
if (nla_len(tb[NL80211_REKEY_DATA_REPLAY_CTR]) != 
NL80211_REPLAY_CTR_LEN)
return -ERANGE;
if (nla_len(tb[NL80211_REKEY_DATA_KEK]) != NL80211_KEK_LEN)
-- 
2.9.5

rtl8821ae keep alive not set, connection lost

2017-09-12 Thread James Cameron 
Summary: 40b368af4b75 ("rtlwifi: Fix alignment issues") breaks
rtl8821ae keep alive, causing "Connection to AP lost" and deauth, but
why?

Wireless connection is lost after a few seconds or minutes, on every
OLPC NL3 laptop with rtl8821ae, with any stable kernel after 4.10.1,
and any kernel with 40b368af4b75.

dmesg contains

  wlp2s0: Connection to AP 2c:b0:5d:a6:86:eb lost

iw event shows

  wlp2s0: del station 2c:b0:5d:a6:86:eb
  wlp2s0 (phy #0): deauth 74:c6:3b:09:b5:0d -> 2c:b0:5d:a6:86:eb reason 4: 
Disassociated due to inactivity
  wlp2s0 (phy #0): disconnected (local request)

Workaround is to bounce the link, then reconnect;

  ip link set wlp2s0 down
  ip link set wlp2s0 up
  iw dev wlp2s0 connect qz

A nearby monitor host captures a deauthentication packet sent by the
device.

Bisection showed cause is 40b368af4b75 ("rtlwifi: Fix alignment
issues") which changes the width of DBI register read.

On the face of it, 40b368af4b75 looks correct, especially compared
against same function in rtl8723be.

I've no idea why reverting fixes the problem.  I'm hoping someone here
might speculate and suggest ways to test.

As keep alive is set through this path, my guess is that keep alive is
not being set in the device.  Or perhaps reading 16-bits perturbs
another register.  Is there a way to test?

http://dev.laptop.org/~quozl/z/1drtGD.txt dmesg of 4.13

http://dev.laptop.org/~quozl/z/1drt7c.txt dmesg with 4.13 and revert
of 40b368af4b75

-- 
James Cameron
http://quozl.netrek.org/

Re: iwlwifi firmware load broken in current -git

2017-09-12 Thread Johannes Berg 
On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:

> CC'ing the guilty part and Bjorn. I'm assuming it's the
> pci_is_enabled() check, since the rest of the patch shouldn't have
> functional changes.

and pci_enable_bridge() already checks if it's already enabled, but
still enables mastering in that case if it isn't:

static void pci_enable_bridge(struct pci_dev *dev)
{
[...]
if (pci_is_enabled(dev)) {
if (!dev->is_busmaster)
pci_set_master(dev);
return;
}

so I guess due to the new check we end up with mastering disabled, and
thus the firmware can't load since that's a DMA thing?

johannes

Re: iwlwifi firmware load broken in current -git

2017-09-12 Thread Luca Coelho 
On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
> On 09/12/2017 10:36 AM, Luca Coelho wrote:
> > On Tue, 2017-09-12 at 16:11 +, Coelho, Luciano wrote:
> > > Hi Jens,
> > > 
> > > On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
> > > > Hi,
> > > > 
> > > > I have no wifi in current git (8fac2f96ab8), it simply fails with:
> > > > 
> > > > [4.363481] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-34.ucode failed with error -2
> > > > [4.363733] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-33.ucode failed with error -2
> > > > [4.363744] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-32.ucode failed with error -2
> > > > [4.368077] iwlwifi :04:00.0: loaded firmware version 
> > > > 31.532993.0 op_mode iwlmvm
> > > > [4.461753] iwlwifi :04:00.0: Detected Intel(R) Dual Band 
> > > > Wireless AC 8260, REV=0x208
> > > > [ ... ]
> > > > [9.510570] iwlwifi :04:00.0: Failed to load firmware chunk! 
> > > > 
> > > > [9.513903] iwlwifi :04:00.0: Could not load the [0] uCode 
> > > > section   
> > > > [9.516201] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
> > > > 
> > > > [9.530842] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
> > > > 
> > > > 
> > > > I get the same thing with -27 of the firmware:
> > > > 
> > > > [   60.990831] Intel(R) Wireless WiFi driver for Linux  
> > > > 
> > > > [   60.990833] Copyright(c) 2003- 2015 Intel Corporation
> > > > 
> > > > [   60.991936] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-34.ucode failed with error -2
> > > > [   60.991941] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-33.ucode failed with error -2
> > > > [   60.991946] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-32.ucode failed with error -2
> > > > [   60.991957] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-31.ucode failed with error -2
> > > > [   60.991964] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-30.ucode failed with error -2
> > > > [   60.991969] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-29.ucode failed with error -2
> > > > [   60.991975] iwlwifi :04:00.0: Direct firmware load for 
> > > > iwlwifi-8000C-28.ucode failed with error -2
> > > > [   61.029852] iwlwifi :04:00.0: loaded firmware version 
> > > > 27.541033.0 op_mode iwlmvm
> > > > [   61.043660] iwlwifi :04:00.0: Detected Intel(R) Dual Band 
> > > > Wireless AC 8260, REV=0x208
> > > > [   66.070135] iwlwifi :04:00.0: Failed to load firmware chunk! 
> > > > 
> > > > [   66.070149] iwlwifi :04:00.0: Could not load the [0] uCode 
> > > > section   
> > > > [   66.070165] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
> > > > 
> > > > [   66.083462] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
> > > > 
> > > > 
> > > > Things work fine in 4.13-rc7+, which was the last kernel I ran on my 
> > > > laptop.
> > > 
> > > This is strange, Linus has been running this same combination with -31
> > > (with -27 we had a regression, but it was fixed recently and the fix is
> > > in the current master).  I have also tried this combination with both
> > > -27 and -31 after my fix and it works fine.
> > > 
> > > There are only a couple of other patches that may affect iwlwifi since
> > > the previous net-next.git pull request...
> > > 
> > > I'll try this combination on my machine and see if I can reproduce the
> > > problem.
> > 
> > I just booted my machine with the latest linux.git/master (8fac2f96ab86)
> > and it works without a problem:
> > 
> > [8.902174] Intel(R) Wireless WiFi driver for Linux
> > [8.902174] Copyright(c) 2003- 2015 Intel Corporation
> > [8.995112] iwlwifi :02:00.0: Direct firmware load for 
> > iwlwifi-8000C-34.ucode failed with error -2
> > [8.995136] iwlwifi :02:00.0: Direct firmware load for 
> > iwlwifi-8000C-33.ucode failed with error -2
> > [9.026455] iwlwifi :02:00.0: Direct firmware load for 
> > iwlwifi-8000C-32.ucode failed with error -2
> > [9.348325] iwlwifi :02:00.0: loaded firmware version 31.532993.0 
> > op_mode iwlmvm
> > [9.369307] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless 
> > AC 8260, REV=0x208
> > [9.435915] iwlwifi :02:00.0: base HW address: 34:13:e8:2d:65:ef
> > [9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
> > 
> > 
> > So this seems to be something that doesn't happen in all machines, maybe
> > a PCIe problem?
> > 
> > Is there any chance you could try to bisect this?
> 
> Bisect done, it tells me that this:
> 
> commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9
> Author: Srinath Mannam 
> Date:   Fri Aug 18 21:50:48 2017 -0500
>

Re: iwlwifi firmware load broken in current -git

2017-09-12 Thread Jens Axboe 
On 09/12/2017 10:36 AM, Luca Coelho wrote:
> On Tue, 2017-09-12 at 16:11 +, Coelho, Luciano wrote:
>> Hi Jens,
>>
>> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> I have no wifi in current git (8fac2f96ab8), it simply fails with:
>>>
>>> [4.363481] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-34.ucode failed with error -2
>>> [4.363733] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-33.ucode failed with error -2
>>> [4.363744] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-32.ucode failed with error -2
>>> [4.368077] iwlwifi :04:00.0: loaded firmware version 31.532993.0 
>>> op_mode iwlmvm
>>> [4.461753] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless 
>>> AC 8260, REV=0x208
>>> [ ... ]
>>> [9.510570] iwlwifi :04:00.0: Failed to load firmware chunk! 
>>> 
>>> [9.513903] iwlwifi :04:00.0: Could not load the [0] uCode section   
>>> 
>>> [9.516201] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
>>> 
>>> [9.530842] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
>>> 
>>>
>>> I get the same thing with -27 of the firmware:
>>>
>>> [   60.990831] Intel(R) Wireless WiFi driver for Linux  
>>> 
>>> [   60.990833] Copyright(c) 2003- 2015 Intel Corporation
>>> 
>>> [   60.991936] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-34.ucode failed with error -2
>>> [   60.991941] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-33.ucode failed with error -2
>>> [   60.991946] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-32.ucode failed with error -2
>>> [   60.991957] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-31.ucode failed with error -2
>>> [   60.991964] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-30.ucode failed with error -2
>>> [   60.991969] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-29.ucode failed with error -2
>>> [   60.991975] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-28.ucode failed with error -2
>>> [   61.029852] iwlwifi :04:00.0: loaded firmware version 27.541033.0 
>>> op_mode iwlmvm
>>> [   61.043660] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless 
>>> AC 8260, REV=0x208
>>> [   66.070135] iwlwifi :04:00.0: Failed to load firmware chunk! 
>>> 
>>> [   66.070149] iwlwifi :04:00.0: Could not load the [0] uCode section   
>>> 
>>> [   66.070165] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
>>> 
>>> [   66.083462] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
>>> 
>>>
>>> Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
>>
>> This is strange, Linus has been running this same combination with -31
>> (with -27 we had a regression, but it was fixed recently and the fix is
>> in the current master).  I have also tried this combination with both
>> -27 and -31 after my fix and it works fine.
>>
>> There are only a couple of other patches that may affect iwlwifi since
>> the previous net-next.git pull request...
>>
>> I'll try this combination on my machine and see if I can reproduce the
>> problem.
> 
> I just booted my machine with the latest linux.git/master (8fac2f96ab86)
> and it works without a problem:
> 
> [8.902174] Intel(R) Wireless WiFi driver for Linux
> [8.902174] Copyright(c) 2003- 2015 Intel Corporation
> [8.995112] iwlwifi :02:00.0: Direct firmware load for 
> iwlwifi-8000C-34.ucode failed with error -2
> [8.995136] iwlwifi :02:00.0: Direct firmware load for 
> iwlwifi-8000C-33.ucode failed with error -2
> [9.026455] iwlwifi :02:00.0: Direct firmware load for 
> iwlwifi-8000C-32.ucode failed with error -2
> [9.348325] iwlwifi :02:00.0: loaded firmware version 31.532993.0 
> op_mode iwlmvm
> [9.369307] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
> 8260, REV=0x208
> [9.435915] iwlwifi :02:00.0: base HW address: 34:13:e8:2d:65:ef
> [9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
> 
> 
> So this seems to be something that doesn't happen in all machines, maybe
> a PCIe problem?
> 
> Is there any chance you could try to bisect this?

Bisect done, it tells me that this:

commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9
Author: Srinath Mannam 
Date:   Fri Aug 18 21:50:48 2017 -0500

PCI: Avoid race while enabling upstream bridges

is the first bad commit. Reverting that on top of master makes things
work fine again, so that commit is definitely b0rken.

CC'ing the guilty part and Bjorn. I'm assuming it's the pci_is_enabled()
check, since the rest of the patch shouldn't have functional changes.

-- 
Jens Axboe

Re: [PATCH 3/3] brcmfmac: Add check for short event packets

2017-09-12 Thread Arend van Spriel 

On 12-09-17 17:04, Kevin Cernekee wrote:

On Mon, Sep 11, 2017 at 12:09 PM, Arend van Spriel
 wrote:

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
index 5aabdc9ed7e0..4cad1f0d2a82 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -429,7 +429,8 @@ void brcmf_fweh_process_event(struct brcmf_pub *drvr,
  if (code != BRCMF_E_IF && !fweh->evt_handler[code])
  return;

-   if (datalen > BRCMF_DCMD_MAXLEN)
+   if (datalen > BRCMF_DCMD_MAXLEN ||
+   datalen + sizeof(*event_packet) < packet_len)



Shouldn't this check be larger-than, i.e. we need the packet to be at
least sizeof(*event_packet) + its payload size?


That depends on how you formulate the requirement. packet_len here is the
length for the received skbuff. The event message (= sizeof(*event_packet))
and its variable payload (= datalen) shall not exceed length of received
skbuff (= packet_len).


Or should it be an exact match, i.e. datalen + sizeof(*event_packet)
!= packet_len


Checking for exact match might not work, because the skbuff length could 
differ because of host interface alignment requirements.



What did Franky's version of the check look like?


the check Franky had was:

datalen > packet_len - sizeof(*event_packet)


If Broadcom has a test suite that tries different event types and
notices if events are getting unexpectedly dropped, that would be
helpful in validating the change.  I would be wary of pushing this to
-stable until we know the check is 100% correct.


Agree. I quickly browsed through our collection of tests in our test 
framework, but found none covering this.


Regards,
Arend

Re: iwlwifi firmware load broken in current -git

2017-09-12 Thread Jens Axboe 
On 09/12/2017 10:36 AM, Luca Coelho wrote:
> On Tue, 2017-09-12 at 16:11 +, Coelho, Luciano wrote:
>> Hi Jens,
>>
>> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> I have no wifi in current git (8fac2f96ab8), it simply fails with:
>>>
>>> [4.363481] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-34.ucode failed with error -2
>>> [4.363733] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-33.ucode failed with error -2
>>> [4.363744] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-32.ucode failed with error -2
>>> [4.368077] iwlwifi :04:00.0: loaded firmware version 31.532993.0 
>>> op_mode iwlmvm
>>> [4.461753] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless 
>>> AC 8260, REV=0x208
>>> [ ... ]
>>> [9.510570] iwlwifi :04:00.0: Failed to load firmware chunk! 
>>> 
>>> [9.513903] iwlwifi :04:00.0: Could not load the [0] uCode section   
>>> 
>>> [9.516201] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
>>> 
>>> [9.530842] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
>>> 
>>>
>>> I get the same thing with -27 of the firmware:
>>>
>>> [   60.990831] Intel(R) Wireless WiFi driver for Linux  
>>> 
>>> [   60.990833] Copyright(c) 2003- 2015 Intel Corporation
>>> 
>>> [   60.991936] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-34.ucode failed with error -2
>>> [   60.991941] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-33.ucode failed with error -2
>>> [   60.991946] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-32.ucode failed with error -2
>>> [   60.991957] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-31.ucode failed with error -2
>>> [   60.991964] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-30.ucode failed with error -2
>>> [   60.991969] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-29.ucode failed with error -2
>>> [   60.991975] iwlwifi :04:00.0: Direct firmware load for 
>>> iwlwifi-8000C-28.ucode failed with error -2
>>> [   61.029852] iwlwifi :04:00.0: loaded firmware version 27.541033.0 
>>> op_mode iwlmvm
>>> [   61.043660] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless 
>>> AC 8260, REV=0x208
>>> [   66.070135] iwlwifi :04:00.0: Failed to load firmware chunk! 
>>> 
>>> [   66.070149] iwlwifi :04:00.0: Could not load the [0] uCode section   
>>> 
>>> [   66.070165] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
>>> 
>>> [   66.083462] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
>>> 
>>>
>>> Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
>>
>> This is strange, Linus has been running this same combination with -31
>> (with -27 we had a regression, but it was fixed recently and the fix is
>> in the current master).  I have also tried this combination with both
>> -27 and -31 after my fix and it works fine.
>>
>> There are only a couple of other patches that may affect iwlwifi since
>> the previous net-next.git pull request...
>>
>> I'll try this combination on my machine and see if I can reproduce the
>> problem.
> 
> I just booted my machine with the latest linux.git/master (8fac2f96ab86)
> and it works without a problem:
> 
> [8.902174] Intel(R) Wireless WiFi driver for Linux
> [8.902174] Copyright(c) 2003- 2015 Intel Corporation
> [8.995112] iwlwifi :02:00.0: Direct firmware load for 
> iwlwifi-8000C-34.ucode failed with error -2
> [8.995136] iwlwifi :02:00.0: Direct firmware load for 
> iwlwifi-8000C-33.ucode failed with error -2
> [9.026455] iwlwifi :02:00.0: Direct firmware load for 
> iwlwifi-8000C-32.ucode failed with error -2
> [9.348325] iwlwifi :02:00.0: loaded firmware version 31.532993.0 
> op_mode iwlmvm
> [9.369307] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
> 8260, REV=0x208
> [9.435915] iwlwifi :02:00.0: base HW address: 34:13:e8:2d:65:ef
> [9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
> 
> 
> So this seems to be something that doesn't happen in all machines, maybe
> a PCIe problem?
> 
> Is there any chance you could try to bisect this?

I can try, but it might be an all day thing on the laptop. I'll get it going.

-- 
Jens Axboe

Re: iwlwifi firmware load broken in current -git

2017-09-12 Thread Luca Coelho 
On Tue, 2017-09-12 at 16:11 +, Coelho, Luciano wrote:
> Hi Jens,
> 
> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
> > Hi,
> > 
> > I have no wifi in current git (8fac2f96ab8), it simply fails with:
> > 
> > [4.363481] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-34.ucode failed with error -2
> > [4.363733] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-33.ucode failed with error -2
> > [4.363744] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-32.ucode failed with error -2
> > [4.368077] iwlwifi :04:00.0: loaded firmware version 31.532993.0 
> > op_mode iwlmvm
> > [4.461753] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless 
> > AC 8260, REV=0x208
> > [ ... ]
> > [9.510570] iwlwifi :04:00.0: Failed to load firmware chunk! 
> > 
> > [9.513903] iwlwifi :04:00.0: Could not load the [0] uCode section   
> > 
> > [9.516201] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
> > 
> > [9.530842] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
> > 
> > 
> > I get the same thing with -27 of the firmware:
> > 
> > [   60.990831] Intel(R) Wireless WiFi driver for Linux  
> > 
> > [   60.990833] Copyright(c) 2003- 2015 Intel Corporation
> > 
> > [   60.991936] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-34.ucode failed with error -2
> > [   60.991941] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-33.ucode failed with error -2
> > [   60.991946] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-32.ucode failed with error -2
> > [   60.991957] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-31.ucode failed with error -2
> > [   60.991964] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-30.ucode failed with error -2
> > [   60.991969] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-29.ucode failed with error -2
> > [   60.991975] iwlwifi :04:00.0: Direct firmware load for 
> > iwlwifi-8000C-28.ucode failed with error -2
> > [   61.029852] iwlwifi :04:00.0: loaded firmware version 27.541033.0 
> > op_mode iwlmvm
> > [   61.043660] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless 
> > AC 8260, REV=0x208
> > [   66.070135] iwlwifi :04:00.0: Failed to load firmware chunk! 
> > 
> > [   66.070149] iwlwifi :04:00.0: Could not load the [0] uCode section   
> > 
> > [   66.070165] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
> > 
> > [   66.083462] iwlwifi :04:00.0: Failed to run INIT ucode: -110 
> > 
> > 
> > Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
> 
> This is strange, Linus has been running this same combination with -31
> (with -27 we had a regression, but it was fixed recently and the fix is
> in the current master).  I have also tried this combination with both
> -27 and -31 after my fix and it works fine.
> 
> There are only a couple of other patches that may affect iwlwifi since
> the previous net-next.git pull request...
> 
> I'll try this combination on my machine and see if I can reproduce the
> problem.

I just booted my machine with the latest linux.git/master (8fac2f96ab86)
and it works without a problem:

[8.902174] Intel(R) Wireless WiFi driver for Linux
[8.902174] Copyright(c) 2003- 2015 Intel Corporation
[8.995112] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-8000C-34.ucode failed with error -2
[8.995136] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-8000C-33.ucode failed with error -2
[9.026455] iwlwifi :02:00.0: Direct firmware load for 
iwlwifi-8000C-32.ucode failed with error -2
[9.348325] iwlwifi :02:00.0: loaded firmware version 31.532993.0 
op_mode iwlmvm
[9.369307] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
8260, REV=0x208
[9.435915] iwlwifi :02:00.0: base HW address: 34:13:e8:2d:65:ef
[9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'


So this seems to be something that doesn't happen in all machines, maybe
a PCIe problem?

Is there any chance you could try to bisect this?

--
Cheers,
Luca.

Re: iwlwifi firmware load broken in current -git

2017-09-12 Thread Jens Axboe 
On 09/12/2017 10:11 AM, Coelho, Luciano wrote:
> Hi Jens,
> 
> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
>> Hi,
>>
>> I have no wifi in current git (8fac2f96ab8), it simply fails with:
>>
>> [4.363481] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-34.ucode failed with error -2
>> [4.363733] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-33.ucode failed with error -2
>> [4.363744] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-32.ucode failed with error -2
>> [4.368077] iwlwifi :04:00.0: loaded firmware version 31.532993.0 
>> op_mode iwlmvm
>> [4.461753] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 
>> 8260, REV=0x208
>> [ ... ]
>> [9.510570] iwlwifi :04:00.0: Failed to load firmware chunk!  
>>
>> [9.513903] iwlwifi :04:00.0: Could not load the [0] uCode section
>>
>> [9.516201] iwlwifi :04:00.0: Failed to start INIT ucode: -110
>>
>> [9.530842] iwlwifi :04:00.0: Failed to run INIT ucode: -110  
>>
>>
>> I get the same thing with -27 of the firmware:
>>
>> [   60.990831] Intel(R) Wireless WiFi driver for Linux   
>>
>> [   60.990833] Copyright(c) 2003- 2015 Intel Corporation 
>>
>> [   60.991936] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-34.ucode failed with error -2
>> [   60.991941] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-33.ucode failed with error -2
>> [   60.991946] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-32.ucode failed with error -2
>> [   60.991957] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-31.ucode failed with error -2
>> [   60.991964] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-30.ucode failed with error -2
>> [   60.991969] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-29.ucode failed with error -2
>> [   60.991975] iwlwifi :04:00.0: Direct firmware load for 
>> iwlwifi-8000C-28.ucode failed with error -2
>> [   61.029852] iwlwifi :04:00.0: loaded firmware version 27.541033.0 
>> op_mode iwlmvm
>> [   61.043660] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 
>> 8260, REV=0x208
>> [   66.070135] iwlwifi :04:00.0: Failed to load firmware chunk!  
>>
>> [   66.070149] iwlwifi :04:00.0: Could not load the [0] uCode section
>>
>> [   66.070165] iwlwifi :04:00.0: Failed to start INIT ucode: -110
>>
>> [   66.083462] iwlwifi :04:00.0: Failed to run INIT ucode: -110  
>>
>>
>> Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
> 
> This is strange, Linus has been running this same combination with -31
> (with -27 we had a regression, but it was fixed recently and the fix is
> in the current master).  I have also tried this combination with both
> -27 and -31 after my fix and it works fine.

It's 100% reproducible, I booted in and out of current -git and 4.13-rc7+
a few times and the latter never works while the former works fine. I
haven't seen this issue before on previous kernels.

> There are only a couple of other patches that may affect iwlwifi since
> the previous net-next.git pull request...
> 
> I'll try this combination on my machine and see if I can reproduce the
> problem.

Let me know if you have something I can try.

-- 
Jens Axboe

Re: iwlwifi firmware load broken in current -git

2017-09-12 Thread Coelho, Luciano 
Hi Jens,

On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
> Hi,
> 
> I have no wifi in current git (8fac2f96ab8), it simply fails with:
> 
> [4.363481] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-34.ucode failed with error -2
> [4.363733] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-33.ucode failed with error -2
> [4.363744] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-32.ucode failed with error -2
> [4.368077] iwlwifi :04:00.0: loaded firmware version 31.532993.0 
> op_mode iwlmvm
> [4.461753] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 
> 8260, REV=0x208
> [ ... ]
> [9.510570] iwlwifi :04:00.0: Failed to load firmware chunk!   
>   
> [9.513903] iwlwifi :04:00.0: Could not load the [0] uCode section 
>   
> [9.516201] iwlwifi :04:00.0: Failed to start INIT ucode: -110 
>   
> [9.530842] iwlwifi :04:00.0: Failed to run INIT ucode: -110   
>   
> 
> I get the same thing with -27 of the firmware:
> 
> [   60.990831] Intel(R) Wireless WiFi driver for Linux
>   
> [   60.990833] Copyright(c) 2003- 2015 Intel Corporation  
>   
> [   60.991936] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-34.ucode failed with error -2
> [   60.991941] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-33.ucode failed with error -2
> [   60.991946] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-32.ucode failed with error -2
> [   60.991957] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-31.ucode failed with error -2
> [   60.991964] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-30.ucode failed with error -2
> [   60.991969] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-29.ucode failed with error -2
> [   60.991975] iwlwifi :04:00.0: Direct firmware load for 
> iwlwifi-8000C-28.ucode failed with error -2
> [   61.029852] iwlwifi :04:00.0: loaded firmware version 27.541033.0 
> op_mode iwlmvm
> [   61.043660] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 
> 8260, REV=0x208
> [   66.070135] iwlwifi :04:00.0: Failed to load firmware chunk!   
>   
> [   66.070149] iwlwifi :04:00.0: Could not load the [0] uCode section 
>   
> [   66.070165] iwlwifi :04:00.0: Failed to start INIT ucode: -110 
>   
> [   66.083462] iwlwifi :04:00.0: Failed to run INIT ucode: -110   
>   
> 
> Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.

This is strange, Linus has been running this same combination with -31
(with -27 we had a regression, but it was fixed recently and the fix is
in the current master).  I have also tried this combination with both
-27 and -31 after my fix and it works fine.

There are only a couple of other patches that may affect iwlwifi since
the previous net-next.git pull request...

I'll try this combination on my machine and see if I can reproduce the
problem.

--
Cheers,
Luca.

iwlwifi firmware load broken in current -git

2017-09-12 Thread Jens Axboe 
Hi,

I have no wifi in current git (8fac2f96ab8), it simply fails with:

[4.363481] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-34.ucode failed with error -2
[4.363733] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-33.ucode failed with error -2
[4.363744] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-32.ucode failed with error -2
[4.368077] iwlwifi :04:00.0: loaded firmware version 31.532993.0 
op_mode iwlmvm
[4.461753] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 
8260, REV=0x208
[ ... ]
[9.510570] iwlwifi :04:00.0: Failed to load firmware chunk! 
[9.513903] iwlwifi :04:00.0: Could not load the [0] uCode section   
[9.516201] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
[9.530842] iwlwifi :04:00.0: Failed to run INIT ucode: -110 

I get the same thing with -27 of the firmware:

[   60.990831] Intel(R) Wireless WiFi driver for Linux  
[   60.990833] Copyright(c) 2003- 2015 Intel Corporation
[   60.991936] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-34.ucode failed with error -2
[   60.991941] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-33.ucode failed with error -2
[   60.991946] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-32.ucode failed with error -2
[   60.991957] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-31.ucode failed with error -2
[   60.991964] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-30.ucode failed with error -2
[   60.991969] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-29.ucode failed with error -2
[   60.991975] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-28.ucode failed with error -2
[   61.029852] iwlwifi :04:00.0: loaded firmware version 27.541033.0 
op_mode iwlmvm
[   61.043660] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 
8260, REV=0x208
[   66.070135] iwlwifi :04:00.0: Failed to load firmware chunk! 
[   66.070149] iwlwifi :04:00.0: Could not load the [0] uCode section   
[   66.070165] iwlwifi :04:00.0: Failed to start INIT ucode: -110   
[   66.083462] iwlwifi :04:00.0: Failed to run INIT ucode: -110 

Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.

-- 
Jens Axboe

Re: [PATCH 3/3] brcmfmac: Add check for short event packets

2017-09-12 Thread Kevin Cernekee 
On Mon, Sep 11, 2017 at 12:09 PM, Arend van Spriel
 wrote:
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> index 5aabdc9ed7e0..4cad1f0d2a82 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> @@ -429,7 +429,8 @@ void brcmf_fweh_process_event(struct brcmf_pub *drvr,
>>>  if (code != BRCMF_E_IF && !fweh->evt_handler[code])
>>>  return;
>>>
>>> -   if (datalen > BRCMF_DCMD_MAXLEN)
>>> +   if (datalen > BRCMF_DCMD_MAXLEN ||
>>> +   datalen + sizeof(*event_packet) < packet_len)
>>
>>
>> Shouldn't this check be larger-than, i.e. we need the packet to be at
>> least sizeof(*event_packet) + its payload size?
>
> That depends on how you formulate the requirement. packet_len here is the
> length for the received skbuff. The event message (= sizeof(*event_packet))
> and its variable payload (= datalen) shall not exceed length of received
> skbuff (= packet_len).

Or should it be an exact match, i.e. datalen + sizeof(*event_packet)
!= packet_len

What did Franky's version of the check look like?

If Broadcom has a test suite that tries different event types and
notices if events are getting unexpectedly dropped, that would be
helpful in validating the change.  I would be wary of pushing this to
-stable until we know the check is 100% correct.

Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read

2017-09-12 Thread Greg KH 
On Tue, Sep 12, 2017 at 10:18:00AM +0200, Arend van Spriel wrote:
> + Greg KH
> 
> On 9/12/2017 10:05 AM, Kalle Valo wrote:
> > Arend van Spriel  writes:
> > 
> > > On 9/12/2017 9:47 AM, Kalle Valo wrote:
> > > > Arend van Spriel  writes:
> > > > 
> > > > > On 9/12/2017 7:48 AM, Kalle Valo wrote:
> > > > > > Arend van Spriel  writes:
> > > > > > 
> > > > > > > On 09-09-17 21:30, Kevin Cernekee wrote:
> > > > > > > > In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is 
> > > > > > > > assigned before
> > > > > > > > the length of rxframe is validated.  This could lead to 
> > > > > > > > uninitialized
> > > > > > > > data being accessed (but not printed).  Since we already have a
> > > > > > > > perfectly good endian-swapped copy of rxframe->chanspec in 
> > > > > > > > ch.chspec,
> > > > > > > > and ch.chspec is not modified by decchspec(), avoid the extra
> > > > > > > > assignment and use ch.chspec in the debug print.
> > > > > > > > 
> > > > > > > > Suggested-by: Mattias Nissler 
> > > > > > > > Signed-off-by: Kevin Cernekee 
> > > > > > > > Reviewed-by: Arend van Spriel 
> > > > > > > > ---
> > > > > > > >  drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 
> > > > > > > > +--
> > > > > > > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > > > > > > 
> > > > > > > > 
> > > > > > > > V1->V2: Clarify changelog re: whether the uninitialized data is 
> > > > > > > > printed.
> > > > > > > 
> > > > > > > This patch and the others in this series look fine to me.
> > > > > > 
> > > > > > Should these go to v4.14?
> > > > > 
> > > > > I have no strong opinion. These are certainly improvements, but it
> > > > > does not seem an -rc fix to me. Within this series I would say patch
> > > > > 3/3 adds an additional sanity check in the event processing against an
> > > > > attack so you may consider adding just that one to v4.14
> > > > 
> > > > Ok, I'll queue patch 3 to v4.14.
> > > > 
> > > > > and tag it for stable, ie.:
> > > > > 
> > > > > Cc: sta...@vger.kernel.org # v3.8.x
> > > > 
> > > > But why v3.8.x? I admit that I haven't fully figured out the stable tags
> > > > yet, but doesn't that mean that it will be only applied to v3.8.x and
> > > > nothing else? I was expecting it to be:
> > > > 
> > > > Cc: sta...@vger.kernel.org # v3.8+
> > > > 
> > > 
> > > It is actually in the stable-kernel-rules documentation [1]:
> > > 
> > > """
> > > Also, some patches may have kernel version prerequisites.  This can be
> > > specified in the following format in the sign-off area:
> > > 
> > > .. code-block:: none
> > > 
> > >   Cc:  # 3.3.x
> > > 
> > > The tag has the meaning of:
> > > 
> > > .. code-block:: none
> > > 
> > >   git cherry-pick 
> > > 
> > > For each "-stable" tree starting with the specified version.
> > > """
> > 
> > Yeah, but it says "starting with" which I interpret as "starting with
> > string '3.3'". For example the commit here would be applied to 3.3.1,
> > 3.3.2 and 3.3.3 etc but _not_ to 3.4, 3.4.1, 3.5 or any later release.
> > 
> > Of course I can be way off here, wouldn't be the first :)
> 
> Dito. I interpret "each -stable tree" as each stable branch in the stable
> repository. Would Greg know?

"# 3.8+" and "# 3.8" mean the same thing to me, we would never backport
something to only a very specific kernel version, and leave newer kernel
versions to not have that fix.  That would be crazy, and would break our
"no regressions" rule (i.e. newer kernels should always work as good as
older kernels.)

Don't get hung up on the semantics here people, it's not all that
complicated, and I do it all by hand anyway :)

thanks,

greg k-h

[PATCH 7/7] brcmfmac: move configuration of probe request IEs

2017-09-12 Thread Arend van Spriel 
The configuration of the IEs for probe requests was done in a P2P
related function, which is not very obvious. Moving it to
.scan callback function, ie. brcmf_cfg80211_scan().

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c  | 6 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 35e9cac..b6d1aaa 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1119,6 +1119,11 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
if (err)
goto scan_out;
 
+   err = brcmf_vif_set_mgmt_ie(vif, BRCMF_VNDR_IE_PRBREQ_FLAG,
+   request->ie, request->ie_len);
+   if (err)
+   goto scan_out;
+
err = brcmf_do_escan(vif->ifp, request);
if (err)
goto scan_out;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index 8e0b3f4..cec25dd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -881,7 +881,7 @@ int brcmf_p2p_scan_prep(struct wiphy *wiphy,
 {
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
struct brcmf_p2p_info *p2p = >p2p;
-   int err = 0;
+   int err;
 
if (brcmf_p2p_scan_is_p2p_request(request)) {
/* find my listen channel */
@@ -904,9 +904,7 @@ int brcmf_p2p_scan_prep(struct wiphy *wiphy,
/* override .run_escan() callback. */
cfg->escan_info.run = brcmf_p2p_run_escan;
}
-   err = brcmf_vif_set_mgmt_ie(vif, BRCMF_VNDR_IE_PRBREQ_FLAG,
-   request->ie, request->ie_len);
-   return err;
+   return 0;
 }
 
 
-- 
1.9.1

[PATCH 4/7] brcmfmac: use msecs_to_jiffies() instead of calculation using HZ

2017-09-12 Thread Arend van Spriel 
Minor cleanup using provided macro to convert milliseconds interval
to jiffies in brcmf_cfg80211_escan().

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 217160e..8e7717a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1126,8 +1126,8 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
goto scan_out;
 
/* Arm scan timeout timer */
-   mod_timer(>escan_timeout, jiffies +
-   BRCMF_ESCAN_TIMER_INTERVAL_MS * HZ / 1000);
+   mod_timer(>escan_timeout,
+ jiffies + msecs_to_jiffies(BRCMF_ESCAN_TIMER_INTERVAL_MS));
 
return 0;
 
-- 
1.9.1

[PATCH 2/7] brcmfmac: disable packet filtering in promiscuous mode

2017-09-12 Thread Arend van Spriel 
From: Franky Lin 

Disable arp and nd offload to allow all packets sending to host.

Reported-by: Phil Elwell 
Tested-by: Phil Elwell 
Reviewed-by: Arend Van Spriel 
Signed-off-by: Franky Lin 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 41 --
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 38 
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  1 +
 3 files changed, 39 insertions(+), 41 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index aaed4ab..b249083 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -472,47 +472,6 @@ static void convert_key_from_CPU(struct brcmf_wsec_key 
*key,
return err;
 }
 
-static s32
-brcmf_configure_arp_nd_offload(struct brcmf_if *ifp, bool enable)
-{
-   s32 err;
-   u32 mode;
-
-   if (enable)
-   mode = BRCMF_ARP_OL_AGENT | BRCMF_ARP_OL_PEER_AUTO_REPLY;
-   else
-   mode = 0;
-
-   /* Try to set and enable ARP offload feature, this may fail, then it  */
-   /* is simply not supported and err 0 will be returned */
-   err = brcmf_fil_iovar_int_set(ifp, "arp_ol", mode);
-   if (err) {
-   brcmf_dbg(TRACE, "failed to set ARP offload mode to 0x%x, err = 
%d\n",
- mode, err);
-   err = 0;
-   } else {
-   err = brcmf_fil_iovar_int_set(ifp, "arpoe", enable);
-   if (err) {
-   brcmf_dbg(TRACE, "failed to configure (%d) ARP offload 
err = %d\n",
- enable, err);
-   err = 0;
-   } else
-   brcmf_dbg(TRACE, "successfully configured (%d) ARP 
offload to 0x%x\n",
- enable, mode);
-   }
-
-   err = brcmf_fil_iovar_int_set(ifp, "ndoe", enable);
-   if (err) {
-   brcmf_dbg(TRACE, "failed to configure (%d) ND offload err = 
%d\n",
- enable, err);
-   err = 0;
-   } else
-   brcmf_dbg(TRACE, "successfully configured (%d) ND offload to 
0x%x\n",
- enable, mode);
-
-   return err;
-}
-
 static void
 brcmf_cfg80211_update_proto_addr_mode(struct wireless_dev *wdev)
 {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 5cc3a07..9c7536d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -71,6 +71,43 @@ struct brcmf_if *brcmf_get_ifp(struct brcmf_pub *drvr, int 
ifidx)
return ifp;
 }
 
+void brcmf_configure_arp_nd_offload(struct brcmf_if *ifp, bool enable)
+{
+   s32 err;
+   u32 mode;
+
+   if (enable)
+   mode = BRCMF_ARP_OL_AGENT | BRCMF_ARP_OL_PEER_AUTO_REPLY;
+   else
+   mode = 0;
+
+   /* Try to set and enable ARP offload feature, this may fail, then it  */
+   /* is simply not supported and err 0 will be returned */
+   err = brcmf_fil_iovar_int_set(ifp, "arp_ol", mode);
+   if (err) {
+   brcmf_dbg(TRACE, "failed to set ARP offload mode to 0x%x, err = 
%d\n",
+ mode, err);
+   } else {
+   err = brcmf_fil_iovar_int_set(ifp, "arpoe", enable);
+   if (err) {
+   brcmf_dbg(TRACE, "failed to configure (%d) ARP offload 
err = %d\n",
+ enable, err);
+   } else {
+   brcmf_dbg(TRACE, "successfully configured (%d) ARP 
offload to 0x%x\n",
+ enable, mode);
+   }
+   }
+
+   err = brcmf_fil_iovar_int_set(ifp, "ndoe", enable);
+   if (err) {
+   brcmf_dbg(TRACE, "failed to configure (%d) ND offload err = 
%d\n",
+ enable, err);
+   } else {
+   brcmf_dbg(TRACE, "successfully configured (%d) ND offload to 
0x%x\n",
+ enable, mode);
+   }
+}
+
 static void _brcmf_set_multicast_list(struct work_struct *work)
 {
struct brcmf_if *ifp;
@@ -134,6 +171,7 @@ static void _brcmf_set_multicast_list(struct work_struct 
*work)
if (err < 0)
brcmf_err("Setting BRCMF_C_SET_PROMISC failed, %d\n",
  err);
+   brcmf_configure_arp_nd_offload(ifp, !cmd_value);
 }
 
 #if IS_ENABLED(CONFIG_IPV6)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index a4dd313..1708571 100644
---

[PATCH 5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function

2017-09-12 Thread Arend van Spriel 
The function brcmf_cfg80211_escan() is only called by brcmf_cfg80211_scan()
so there is no reason to split in two function especially since the latter
does not do an awful lot.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 34 +++---
 1 file changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 8e7717a..34c2945 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1082,13 +1082,16 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
 }
 
 static s32
-brcmf_cfg80211_escan(struct wiphy *wiphy, struct brcmf_cfg80211_vif *vif,
-struct cfg80211_scan_request *request)
+brcmf_cfg80211_scan(struct wiphy *wiphy, struct cfg80211_scan_request *request)
 {
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
-   s32 err;
+   struct brcmf_cfg80211_vif *vif;
+   s32 err = 0;
 
-   brcmf_dbg(SCAN, "START ESCAN\n");
+   brcmf_dbg(TRACE, "Enter\n");
+   vif = container_of(request->wdev, struct brcmf_cfg80211_vif, wdev);
+   if (!check_vif_up(vif))
+   return -EIO;
 
if (test_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status)) {
brcmf_err("Scanning already: status (%lu)\n", cfg->scan_status);
@@ -1113,6 +1116,8 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif)
vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif;
 
+   brcmf_dbg(SCAN, "START ESCAN\n");
+
cfg->scan_request = request;
set_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status);
 
@@ -1132,31 +1137,12 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
return 0;
 
 scan_out:
+   brcmf_err("scan error (%d)\n", err);
clear_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status);
cfg->scan_request = NULL;
return err;
 }
 
-static s32
-brcmf_cfg80211_scan(struct wiphy *wiphy, struct cfg80211_scan_request *request)
-{
-   struct brcmf_cfg80211_vif *vif;
-   s32 err = 0;
-
-   brcmf_dbg(TRACE, "Enter\n");
-   vif = container_of(request->wdev, struct brcmf_cfg80211_vif, wdev);
-   if (!check_vif_up(vif))
-   return -EIO;
-
-   err = brcmf_cfg80211_escan(wiphy, vif, request);
-
-   if (err)
-   brcmf_err("scan error (%d)\n", err);
-
-   brcmf_dbg(TRACE, "Exit\n");
-   return err;
-}
-
 static s32 brcmf_set_rts(struct net_device *ndev, u32 rts_threshold)
 {
s32 err = 0;
-- 
1.9.1

[PATCH 3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function

2017-09-12 Thread Arend van Spriel 
The function brcmf_cfg80211_escan() was always called with a non-null
request parameter and null pointer for this_ssid parameter. Clean up
the function removing the dead code path.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 76 --
 1 file changed, 11 insertions(+), 65 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b249083..217160e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1083,18 +1083,10 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
 
 static s32
 brcmf_cfg80211_escan(struct wiphy *wiphy, struct brcmf_cfg80211_vif *vif,
-struct cfg80211_scan_request *request,
-struct cfg80211_ssid *this_ssid)
+struct cfg80211_scan_request *request)
 {
-   struct brcmf_if *ifp = vif->ifp;
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
-   struct cfg80211_ssid *ssids;
-   u32 passive_scan;
-   bool escan_req;
-   bool spec_scan;
s32 err;
-   struct brcmf_ssid_le ssid_le;
-   u32 SSID_len;
 
brcmf_dbg(SCAN, "START ESCAN\n");
 
@@ -1112,8 +1104,8 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
  cfg->scan_status);
return -EAGAIN;
}
-   if (test_bit(BRCMF_VIF_STATUS_CONNECTING, >vif->sme_state)) {
-   brcmf_err("Connecting: status (%lu)\n", ifp->vif->sme_state);
+   if (test_bit(BRCMF_VIF_STATUS_CONNECTING, >sme_state)) {
+   brcmf_err("Connecting: status (%lu)\n", vif->sme_state);
return -EAGAIN;
}
 
@@ -1121,63 +1113,17 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
if (vif == cfg->p2p.bss_idx[P2PAPI_BSSCFG_DEVICE].vif)
vif = cfg->p2p.bss_idx[P2PAPI_BSSCFG_PRIMARY].vif;
 
-   escan_req = false;
-   if (request) {
-   /* scan bss */
-   ssids = request->ssids;
-   escan_req = true;
-   } else {
-   /* scan in ibss */
-   /* we don't do escan in ibss */
-   ssids = this_ssid;
-   }
-
cfg->scan_request = request;
set_bit(BRCMF_SCAN_STATUS_BUSY, >scan_status);
-   if (escan_req) {
-   cfg->escan_info.run = brcmf_run_escan;
-   err = brcmf_p2p_scan_prep(wiphy, request, vif);
-   if (err)
-   goto scan_out;
-
-   err = brcmf_do_escan(vif->ifp, request);
-   if (err)
-   goto scan_out;
-   } else {
-   brcmf_dbg(SCAN, "ssid \"%s\", ssid_len (%d)\n",
- ssids->ssid, ssids->ssid_len);
-   memset(_le, 0, sizeof(ssid_le));
-   SSID_len = min_t(u8, sizeof(ssid_le.SSID), ssids->ssid_len);
-   ssid_le.SSID_len = cpu_to_le32(0);
-   spec_scan = false;
-   if (SSID_len) {
-   memcpy(ssid_le.SSID, ssids->ssid, SSID_len);
-   ssid_le.SSID_len = cpu_to_le32(SSID_len);
-   spec_scan = true;
-   } else
-   brcmf_dbg(SCAN, "Broadcast scan\n");
 
-   passive_scan = cfg->active_scan ? 0 : 1;
-   err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_PASSIVE_SCAN,
-   passive_scan);
-   if (err) {
-   brcmf_err("WLC_SET_PASSIVE_SCAN error (%d)\n", err);
-   goto scan_out;
-   }
-   brcmf_scan_config_mpc(ifp, 0);
-   err = brcmf_fil_cmd_data_set(ifp, BRCMF_C_SCAN, _le,
-sizeof(ssid_le));
-   if (err) {
-   if (err == -EBUSY)
-   brcmf_dbg(INFO, "BUSY: scan for \"%s\" 
canceled\n",
- ssid_le.SSID);
-   else
-   brcmf_err("WLC_SCAN error (%d)\n", err);
+   cfg->escan_info.run = brcmf_run_escan;
+   err = brcmf_p2p_scan_prep(wiphy, request, vif);
+   if (err)
+   goto scan_out;
 
-   brcmf_scan_config_mpc(ifp, 1);
-   goto scan_out;
-   }
-   }
+   err = brcmf_do_escan(vif->ifp, request);
+   if (err)
+   goto scan_out;
 
/* Arm scan timeout timer */
mod_timer(>escan_timeout, jiffies +
@@ -1202,7 +1148,7 @@ static void brcmf_escan_prep(struct

[PATCH 0/7] brcmfmac: scan code cleanup and more

2017-09-12 Thread Arend van Spriel 
This series has following changes:
 * cleanup scanning code.
 * deal with FWHALT indication.
 * fix for promiscuous mode.

The patches apply to master branch of wireless-drivers-next
repository.

Arend van Spriel (6):
  brcmfmac: handle FWHALT mailbox indication
  brcmfmac: cleanup brcmf_cfg80211_escan() function
  brcmfmac: use msecs_to_jiffies() instead of calculation using HZ
  brcmfmac: get rid of brcmf_cfg80211_escan() function
  brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field
  brcmfmac: move configuration of probe request IEs

Franky Lin (1):
  brcmfmac: disable packet filtering in promiscuous mode

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 162 -
 .../broadcom/brcm80211/brcmfmac/cfg80211.h |   2 -
 .../wireless/broadcom/brcm80211/brcmfmac/core.c|  38 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|   1 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  11 +-
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  14 +-
 6 files changed, 77 insertions(+), 151 deletions(-)

-- 
1.9.1

[PATCH 1/7] brcmfmac: handle FWHALT mailbox indication

2017-09-12 Thread Arend van Spriel 
The firmware uses a mailbox to communicate to the host what is going
on. In the driver we validate the bit received. Various people seen
the following message:

 brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Bit 4 is cause of this message, but this actually indicates the firmware
has halted. Handle this bit by giving a more meaningful error message.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 613caca..3d79664 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -260,10 +260,11 @@ struct rte_console {
 #define I_HMB_HOST_INT I_HMB_SW3   /* Miscellaneous Interrupt */
 
 /* tohostmailboxdata */
-#define HMB_DATA_NAKHANDLED1   /* retransmit NAK'd frame */
-#define HMB_DATA_DEVREADY  2   /* talk to host after enable */
-#define HMB_DATA_FC4   /* per prio flowcontrol update flag */
-#define HMB_DATA_FWREADY   8   /* fw ready for protocol activity */
+#define HMB_DATA_NAKHANDLED0x0001  /* retransmit NAK'd frame */
+#define HMB_DATA_DEVREADY  0x0002  /* talk to host after enable */
+#define HMB_DATA_FC0x0004  /* per prio flowcontrol update flag */
+#define HMB_DATA_FWREADY   0x0008  /* fw ready for protocol activity */
+#define HMB_DATA_FWHALT0x0010  /* firmware halted */
 
 #define HMB_DATA_FCDATA_MASK   0xff00
 #define HMB_DATA_FCDATA_SHIFT  24
@@ -1094,6 +1095,10 @@ static u32 brcmf_sdio_hostmail(struct brcmf_sdio *bus)
  offsetof(struct sdpcmd_regs, tosbmailbox));
bus->sdcnt.f1regdata += 2;
 
+   /* dongle indicates the firmware has halted/crashed */
+   if (hmb_data & HMB_DATA_FWHALT)
+   brcmf_err("mailbox indicates firmware halted\n");
+
/* Dongle recomposed rx frames, accept them again */
if (hmb_data & HMB_DATA_NAKHANDLED) {
brcmf_dbg(SDIO, "Dongle reports NAK handled, expect rtx of 
%d\n",
@@ -1151,6 +1156,7 @@ static u32 brcmf_sdio_hostmail(struct brcmf_sdio *bus)
 HMB_DATA_NAKHANDLED |
 HMB_DATA_FC |
 HMB_DATA_FWREADY |
+HMB_DATA_FWHALT |
 HMB_DATA_FCDATA_MASK | HMB_DATA_VERSION_MASK))
brcmf_err("Unknown mailbox data content: 0x%02x\n",
  hmb_data);
-- 
1.9.1

[PATCH 6/7] brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field

2017-09-12 Thread Arend van Spriel 
The field struct brcmf_cfg80211_info::active_scan is set to true upon
initializing the driver instance, but it is never changed so simply
get rid of it.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 10 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h |  2 --
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c  |  5 +
 3 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 34c2945..35e9cac 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1054,7 +1054,6 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
 {
struct brcmf_cfg80211_info *cfg = ifp->drvr->config;
s32 err;
-   u32 passive_scan;
struct brcmf_scan_results *results;
struct escan_info *escan = >escan_info;
 
@@ -1062,13 +1061,7 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
escan->ifp = ifp;
escan->wiphy = cfg->wiphy;
escan->escan_state = WL_ESCAN_STATE_SCANNING;
-   passive_scan = cfg->active_scan ? 0 : 1;
-   err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_PASSIVE_SCAN,
-   passive_scan);
-   if (err) {
-   brcmf_err("error (%d)\n", err);
-   return err;
-   }
+
brcmf_scan_config_mpc(ifp, 0);
results = (struct brcmf_scan_results *)cfg->escan_info.escan_buf;
results->version = 0;
@@ -5767,7 +5760,6 @@ static s32 wl_init_priv(struct brcmf_cfg80211_info *cfg)
 
cfg->scan_request = NULL;
cfg->pwr_save = true;
-   cfg->active_scan = true;/* we do active scan per default */
cfg->dongle_up = false; /* dongle is not up yet */
err = brcmf_init_priv_mem(cfg);
if (err)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index 7b2835e..b5b5f0f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -283,7 +283,6 @@ struct brcmf_cfg80211_wowl {
  * @scan_status: scan activity on the dongle.
  * @pub: common driver information.
  * @channel: current channel.
- * @active_scan: current scan mode.
  * @int_escan_map: bucket map for which internal e-scan is done.
  * @ibss_starter: indicates this sta is ibss starter.
  * @pwr_save: indicate whether dongle to support power save mode.
@@ -316,7 +315,6 @@ struct brcmf_cfg80211_info {
unsigned long scan_status;
struct brcmf_pub *pub;
u32 channel;
-   bool active_scan;
u32 int_escan_map;
bool ibss_starter;
bool pwr_save;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index 2ce675a..8e0b3f4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -692,10 +692,7 @@ static s32 brcmf_p2p_escan(struct brcmf_p2p_info *p2p, u32 
num_chans,
 
/* determine the scan engine parameters */
sparams->bss_type = DOT11_BSSTYPE_ANY;
-   if (p2p->cfg->active_scan)
-   sparams->scan_type = 0;
-   else
-   sparams->scan_type = 1;
+   sparams->scan_type = BRCMF_SCANTYPE_ACTIVE;
 
eth_broadcast_addr(sparams->bssid);
sparams->home_time = cpu_to_le32(P2PAPI_SCAN_HOME_TIME_MS);
-- 
1.9.1

[PATCH for-4.14 1/2] brcmfmac: add length check in brcmf_cfg80211_escan_handler()

2017-09-12 Thread Arend van Spriel 
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: sta...@vger.kernel.org # v4.0.x
Cc: Kevin Cernekee 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c| 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index aaed4ab..26a0de3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3162,6 +3162,7 @@ static void brcmf_escan_timeout(unsigned long data)
struct brcmf_cfg80211_info *cfg = ifp->drvr->config;
s32 status;
struct brcmf_escan_result_le *escan_result_le;
+   u32 escan_buflen;
struct brcmf_bss_info_le *bss_info_le;
struct brcmf_bss_info_le *bss = NULL;
u32 bi_length;
@@ -3181,11 +3182,23 @@ static void brcmf_escan_timeout(unsigned long data)
 
if (status == BRCMF_E_STATUS_PARTIAL) {
brcmf_dbg(SCAN, "ESCAN Partial result\n");
+   if (e->datalen < sizeof(*escan_result_le)) {
+   brcmf_err("invalid event data length\n");
+   goto exit;
+   }
escan_result_le = (struct brcmf_escan_result_le *) data;
if (!escan_result_le) {
brcmf_err("Invalid escan result (NULL pointer)\n");
goto exit;
}
+   escan_buflen = le32_to_cpu(escan_result_le->buflen);
+   if (escan_buflen > BRCMF_ESCAN_BUF_SIZE ||
+   escan_buflen > e->datalen ||
+   escan_buflen < sizeof(*escan_result_le)) {
+   brcmf_err("Invalid escan buffer length: %d\n",
+ escan_buflen);
+   goto exit;
+   }
if (le16_to_cpu(escan_result_le->bss_count) != 1) {
brcmf_err("Invalid bss_count %d: ignoring\n",
  escan_result_le->bss_count);
@@ -3202,9 +3215,8 @@ static void brcmf_escan_timeout(unsigned long data)
}
 
bi_length = le32_to_cpu(bss_info_le->length);
-   if (bi_length != (le32_to_cpu(escan_result_le->buflen) -
-   WL_ESCAN_RESULTS_FIXED_SIZE)) {
-   brcmf_err("Invalid bss_info length %d: ignoring\n",
+   if (bi_length != escan_buflen - WL_ESCAN_RESULTS_FIXED_SIZE) {
+   brcmf_err("Ignoring invalid bss_info length: %d\n",
  bi_length);
goto exit;
}
-- 
1.9.1

[PATCH for-4.14 2/2] brcmfmac: setup passive scan if requested by user-space

2017-09-12 Thread Arend van Spriel 
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.

Cc: sta...@vger.kernel.org # v4.0.x
Reported-by: Huang, Jiangyang 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c   | 19 ---
 .../wireless/broadcom/brcm80211/brcmfmac/fwil_types.h |  5 +
 2 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 26a0de3..4157c90 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -980,7 +980,7 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
 
eth_broadcast_addr(params_le->bssid);
params_le->bss_type = DOT11_BSSTYPE_ANY;
-   params_le->scan_type = 0;
+   params_le->scan_type = BRCMF_SCANTYPE_ACTIVE;
params_le->channel_num = 0;
params_le->nprobes = cpu_to_le32(-1);
params_le->active_time = cpu_to_le32(-1);
@@ -988,12 +988,9 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
params_le->home_time = cpu_to_le32(-1);
memset(_le->ssid_le, 0, sizeof(params_le->ssid_le));
 
-   /* if request is null exit so it will be all channel broadcast scan */
-   if (!request)
-   return;
-
n_ssids = request->n_ssids;
n_channels = request->n_channels;
+
/* Copy channel array if applicable */
brcmf_dbg(SCAN, "### List of channelspecs to scan ### %d\n",
  n_channels);
@@ -1030,16 +1027,8 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info 
*cfg,
ptr += sizeof(ssid_le);
}
} else {
-   brcmf_dbg(SCAN, "Broadcast scan %p\n", request->ssids);
-   if ((request->ssids) && request->ssids->ssid_len) {
-   brcmf_dbg(SCAN, "SSID %s len=%d\n",
- params_le->ssid_le.SSID,
- request->ssids->ssid_len);
-   params_le->ssid_le.SSID_len =
-   cpu_to_le32(request->ssids->ssid_len);
-   memcpy(_le->ssid_le.SSID, request->ssids->ssid,
-   request->ssids->ssid_len);
-   }
+   brcmf_dbg(SCAN, "Performing passive scan\n");
+   params_le->scan_type = BRCMF_SCANTYPE_PASSIVE;
}
/* Adding mask to channel numbers */
params_le->channel_num =
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 8391989..e0d22fe 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -45,6 +45,11 @@
 #define BRCMF_SCAN_PARAMS_COUNT_MASK   0x
 #define BRCMF_SCAN_PARAMS_NSSID_SHIFT  16
 
+/* scan type definitions */
+#define BRCMF_SCANTYPE_DEFAULT 0xFF
+#define BRCMF_SCANTYPE_ACTIVE  0
+#define BRCMF_SCANTYPE_PASSIVE 1
+
 #define BRCMF_WSEC_MAX_PSK_LEN 32
 #defineBRCMF_WSEC_PASSPHRASE   BIT(0)
 
-- 
1.9.1

[PATCH for-4.14 0/2] brcmfmac: scan related fixes

2017-09-12 Thread Arend van Spriel 
Two patches related to scanning functionality in the driver. The first
patch addresses a security vulnerability in firmware notification
handling. The second one fixes a reported API issue in which the driver
ignored a passive scan request from user-space.

The patches apply to the master branch of the wireless-drivers
repository.

Arend van Spriel (2):
  brcmfmac: add length check in brcmf_cfg80211_escan_handler()
  brcmfmac: setup passive scan if requested by user-space

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37 +++---
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  5 +++
 2 files changed, 24 insertions(+), 18 deletions(-)

-- 
1.9.1

Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read

2017-09-12 Thread Arend van Spriel 

+ Greg KH

On 9/12/2017 10:05 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 9/12/2017 9:47 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 9/12/2017 7:48 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 09-09-17 21:30, Kevin Cernekee wrote:

In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
the length of rxframe is validated.  This could lead to uninitialized
data being accessed (but not printed).  Since we already have a
perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
and ch.chspec is not modified by decchspec(), avoid the extra
assignment and use ch.chspec in the debug print.

Suggested-by: Mattias Nissler 
Signed-off-by: Kevin Cernekee 
Reviewed-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)


V1->V2: Clarify changelog re: whether the uninitialized data is printed.


This patch and the others in this series look fine to me.


Should these go to v4.14?


I have no strong opinion. These are certainly improvements, but it
does not seem an -rc fix to me. Within this series I would say patch
3/3 adds an additional sanity check in the event processing against an
attack so you may consider adding just that one to v4.14


Ok, I'll queue patch 3 to v4.14.


and tag it for stable, ie.:

Cc: sta...@vger.kernel.org # v3.8.x


But why v3.8.x? I admit that I haven't fully figured out the stable tags
yet, but doesn't that mean that it will be only applied to v3.8.x and
nothing else? I was expecting it to be:

Cc: sta...@vger.kernel.org # v3.8+



It is actually in the stable-kernel-rules documentation [1]:

"""
Also, some patches may have kernel version prerequisites.  This can be
specified in the following format in the sign-off area:

.. code-block:: none

  Cc:  # 3.3.x

The tag has the meaning of:

.. code-block:: none

  git cherry-pick 

For each "-stable" tree starting with the specified version.
"""


Yeah, but it says "starting with" which I interpret as "starting with
string '3.3'". For example the commit here would be applied to 3.3.1,
3.3.2 and 3.3.3 etc but _not_ to 3.4, 3.4.1, 3.5 or any later release.

Of course I can be way off here, wouldn't be the first :)


Dito. I interpret "each -stable tree" as each stable branch in the 
stable repository. Would Greg know?


Regards,
Arend

Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read

2017-09-12 Thread Kalle Valo 
Arend van Spriel  writes:

> On 9/12/2017 9:47 AM, Kalle Valo wrote:
>> Arend van Spriel  writes:
>>
>>> On 9/12/2017 7:48 AM, Kalle Valo wrote:
 Arend van Spriel  writes:

> On 09-09-17 21:30, Kevin Cernekee wrote:
>> In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
>> the length of rxframe is validated.  This could lead to uninitialized
>> data being accessed (but not printed).  Since we already have a
>> perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
>> and ch.chspec is not modified by decchspec(), avoid the extra
>> assignment and use ch.chspec in the debug print.
>>
>> Suggested-by: Mattias Nissler 
>> Signed-off-by: Kevin Cernekee 
>> Reviewed-by: Arend van Spriel 
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>>
>> V1->V2: Clarify changelog re: whether the uninitialized data is printed.
>
> This patch and the others in this series look fine to me.

 Should these go to v4.14?
>>>
>>> I have no strong opinion. These are certainly improvements, but it
>>> does not seem an -rc fix to me. Within this series I would say patch
>>> 3/3 adds an additional sanity check in the event processing against an
>>> attack so you may consider adding just that one to v4.14
>>
>> Ok, I'll queue patch 3 to v4.14.
>>
>>> and tag it for stable, ie.:
>>>
>>> Cc: sta...@vger.kernel.org # v3.8.x
>>
>> But why v3.8.x? I admit that I haven't fully figured out the stable tags
>> yet, but doesn't that mean that it will be only applied to v3.8.x and
>> nothing else? I was expecting it to be:
>>
>> Cc: sta...@vger.kernel.org # v3.8+
>>
>
> It is actually in the stable-kernel-rules documentation [1]:
>
> """
> Also, some patches may have kernel version prerequisites.  This can be
> specified in the following format in the sign-off area:
>
> .. code-block:: none
>
>  Cc:  # 3.3.x
>
> The tag has the meaning of:
>
> .. code-block:: none
>
>  git cherry-pick 
>
> For each "-stable" tree starting with the specified version.
> """

Yeah, but it says "starting with" which I interpret as "starting with
string '3.3'". For example the commit here would be applied to 3.3.1,
3.3.2 and 3.3.3 etc but _not_ to 3.4, 3.4.1, 3.5 or any later release.

Of course I can be way off here, wouldn't be the first :)

-- 
Kalle Valo

Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read

2017-09-12 Thread Arend van Spriel 

On 9/12/2017 9:47 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 9/12/2017 7:48 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 09-09-17 21:30, Kevin Cernekee wrote:

In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
the length of rxframe is validated.  This could lead to uninitialized
data being accessed (but not printed).  Since we already have a
perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
and ch.chspec is not modified by decchspec(), avoid the extra
assignment and use ch.chspec in the debug print.

Suggested-by: Mattias Nissler 
Signed-off-by: Kevin Cernekee 
Reviewed-by: Arend van Spriel 
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)


V1->V2: Clarify changelog re: whether the uninitialized data is printed.


This patch and the others in this series look fine to me.


Should these go to v4.14?


I have no strong opinion. These are certainly improvements, but it
does not seem an -rc fix to me. Within this series I would say patch
3/3 adds an additional sanity check in the event processing against an
attack so you may consider adding just that one to v4.14


Ok, I'll queue patch 3 to v4.14.


and tag it for stable, ie.:

Cc: sta...@vger.kernel.org # v3.8.x


But why v3.8.x? I admit that I haven't fully figured out the stable tags
yet, but doesn't that mean that it will be only applied to v3.8.x and
nothing else? I was expecting it to be:

Cc: sta...@vger.kernel.org # v3.8+



It is actually in the stable-kernel-rules documentation [1]:

"""
Also, some patches may have kernel version prerequisites.  This can be
specified in the following format in the sign-off area:

.. code-block:: none

 Cc:  # 3.3.x

The tag has the meaning of:

.. code-block:: none

 git cherry-pick 

For each "-stable" tree starting with the specified version.
"""

The event handling code was added in v3.8.

Regards,
Arend

[1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read

2017-09-12 Thread Kalle Valo 
Arend van Spriel  writes:

> On 9/12/2017 7:48 AM, Kalle Valo wrote:
>> Arend van Spriel  writes:
>>
>>> On 09-09-17 21:30, Kevin Cernekee wrote:
 In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
 the length of rxframe is validated.  This could lead to uninitialized
 data being accessed (but not printed).  Since we already have a
 perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
 and ch.chspec is not modified by decchspec(), avoid the extra
 assignment and use ch.chspec in the debug print.

 Suggested-by: Mattias Nissler 
 Signed-off-by: Kevin Cernekee 
 Reviewed-by: Arend van Spriel 
 ---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)


 V1->V2: Clarify changelog re: whether the uninitialized data is printed.
>>>
>>> This patch and the others in this series look fine to me.
>>
>> Should these go to v4.14?
>
> I have no strong opinion. These are certainly improvements, but it
> does not seem an -rc fix to me. Within this series I would say patch
> 3/3 adds an additional sanity check in the event processing against an
> attack so you may consider adding just that one to v4.14

Ok, I'll queue patch 3 to v4.14.

> and tag it for stable, ie.:
>
> Cc: sta...@vger.kernel.org # v3.8.x

But why v3.8.x? I admit that I haven't fully figured out the stable tags
yet, but doesn't that mean that it will be only applied to v3.8.x and
nothing else? I was expecting it to be:

Cc: sta...@vger.kernel.org # v3.8+

-- 
Kalle Valo

Re: [V2,3/3] brcmfmac: Add check for short event packets

2017-09-12 Thread Kalle Valo 
Kevin Cernekee  wrote:

> 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 
> Reviewed-by: Arend van Spriel 

I'll queue this for v4.14 and add:

Cc: sta...@vger.kernel.org # v3.8+

-- 
https://patchwork.kernel.org/patch/9945427/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read

2017-09-12 Thread Arend van Spriel 

On 9/12/2017 7:48 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 09-09-17 21:30, Kevin Cernekee wrote:

In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
the length of rxframe is validated.  This could lead to uninitialized
data being accessed (but not printed).  Since we already have a
perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
and ch.chspec is not modified by decchspec(), avoid the extra
assignment and use ch.chspec in the debug print.

Suggested-by: Mattias Nissler 
Signed-off-by: Kevin Cernekee 
Reviewed-by: Arend van Spriel 
---
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)


V1->V2: Clarify changelog re: whether the uninitialized data is printed.


This patch and the others in this series look fine to me.


Should these go to v4.14?


I have no strong opinion. These are certainly improvements, but it does 
not seem an -rc fix to me. Within this series I would say patch 3/3 adds 
an additional sanity check in the event processing against an attack so 
you may consider adding just that one to v4.14 and tag it for stable, ie.:


Cc: sta...@vger.kernel.org # v3.8.x

Regards,
Arend

Re: [PATCH] mwifiex: check for mfg_mode in add_virtual_intf

2017-09-12 Thread Kalle Valo 
Brian Norris  writes:

> Could have used a 'v2' in the subject, but hopefully that doesn't bother
> Kalle too much.

It does create more work for me when sorting patches so please always
try include the version in the subject. But no need to resend.

-- 
Kalle Valo