Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
Greg KHwrites: > 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
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
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
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
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
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 MannamDate: 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
On 12-09-17 17:04, Kevin Cernekee wrote: On Mon, Sep 11, 2017 at 12:09 PM, Arend van Sprielwrote: 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
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
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
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
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
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
On Mon, Sep 11, 2017 at 12:09 PM, Arend van Sprielwrote: >>> 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
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 Sprielwrites: > > > > > 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
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 MeulemanReviewed-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
Minor cleanup using provided macro to convert milliseconds interval to jiffies in brcmf_cfg80211_escan(). Reviewed-by: Hante MeulemanReviewed-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
From: Franky LinDisable 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
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 MeulemanReviewed-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
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 MeulemanReviewed-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
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
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 MeulemanReviewed-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
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 MeulemanReviewed-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()
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 CernekeeReviewed-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
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, JiangyangReviewed-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
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
+ Greg KH On 9/12/2017 10:05 AM, Kalle Valo wrote: Arend van Sprielwrites: 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
Arend van Sprielwrites: > 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
On 9/12/2017 9:47 AM, Kalle Valo wrote: Arend van Sprielwrites: 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
Arend van Sprielwrites: > 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
Kevin Cernekeewrote: > 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
On 9/12/2017 7:48 AM, Kalle Valo wrote: Arend van Sprielwrites: 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
Brian Norriswrites: > 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