* [PATCH 7/7] brcmfmac: move configuration of probe request IEs
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
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 <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
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 = &cfg->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
^ permalink raw reply related
* [PATCH 3/7] brcmfmac: cleanup brcmf_cfg80211_escan() function
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
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 <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../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, &ifp->vif->sme_state)) {
- brcmf_err("Connecting: status (%lu)\n", ifp->vif->sme_state);
+ if (test_bit(BRCMF_VIF_STATUS_CONNECTING, &vif->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, &cfg->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(&ssid_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, &ssid_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(&cfg->escan_timeout, jiffies +
@@ -1202,7 +1148,7 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
if (!check_vif_up(vif))
return -EIO;
- err = brcmf_cfg80211_escan(wiphy, vif, request, NULL);
+ err = brcmf_cfg80211_escan(wiphy, vif, request);
if (err)
brcmf_err("scan error (%d)\n", err);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/7] brcmfmac: disable packet filtering in promiscuous mode
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Franky Lin
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
From: Franky Lin <franky.lin@broadcom.com>
Disable arp and nd offload to allow all packets sending to host.
Reported-by: Phil Elwell <phil@raspberrypi.org>
Tested-by: Phil Elwell <phil@raspberrypi.org>
Reviewed-by: Arend Van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Franky Lin <franky.lin@broadcom.com>
---
.../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
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -203,6 +203,7 @@ struct brcmf_if {
/* Return pointer to interface name */
char *brcmf_ifname(struct brcmf_if *ifp);
struct brcmf_if *brcmf_get_ifp(struct brcmf_pub *drvr, int ifidx);
+void brcmf_configure_arp_nd_offload(struct brcmf_if *ifp, bool enable);
int brcmf_net_attach(struct brcmf_if *ifp, bool rtnl_locked);
struct brcmf_if *brcmf_add_if(struct brcmf_pub *drvr, s32 bsscfgidx, s32 ifidx,
bool is_p2pdev, const char *name, u8 *mac_addr);
--
1.9.1
^ permalink raw reply related
* [PATCH 0/7] brcmfmac: scan code cleanup and more
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, 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
^ permalink raw reply
* [PATCH 4/7] brcmfmac: use msecs_to_jiffies() instead of calculation using HZ
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
Minor cleanup using provided macro to convert milliseconds interval
to jiffies in brcmf_cfg80211_escan().
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
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(&cfg->escan_timeout, jiffies +
- BRCMF_ESCAN_TIMER_INTERVAL_MS * HZ / 1000);
+ mod_timer(&cfg->escan_timeout,
+ jiffies + msecs_to_jiffies(BRCMF_ESCAN_TIMER_INTERVAL_MS));
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 6/7] brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
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 <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
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 = &cfg->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
^ permalink raw reply related
* [PATCH 1/7] brcmfmac: handle FWHALT mailbox indication
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
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 <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
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_NAKHANDLED 1 /* retransmit NAK'd frame */
-#define HMB_DATA_DEVREADY 2 /* talk to host after enable */
-#define HMB_DATA_FC 4 /* per prio flowcontrol update flag */
-#define HMB_DATA_FWREADY 8 /* fw ready for protocol activity */
+#define HMB_DATA_NAKHANDLED 0x0001 /* retransmit NAK'd frame */
+#define HMB_DATA_DEVREADY 0x0002 /* talk to host after enable */
+#define HMB_DATA_FC 0x0004 /* per prio flowcontrol update flag */
+#define HMB_DATA_FWREADY 0x0008 /* fw ready for protocol activity */
+#define HMB_DATA_FWHALT 0x0010 /* firmware halted */
#define HMB_DATA_FCDATA_MASK 0xff000000
#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
^ permalink raw reply related
* [PATCH 5/7] brcmfmac: get rid of brcmf_cfg80211_escan() function
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
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 <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../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, &cfg->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, &cfg->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, &cfg->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
^ permalink raw reply related
* [PATCH for-4.14 2/2] brcmfmac: setup passive scan if requested by user-space
From: Arend van Spriel @ 2017-09-12 8:47 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505206074-28781-1-git-send-email-arend.vanspriel@broadcom.com>
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: stable@vger.kernel.org # v4.0.x
Reported-by: Huang, Jiangyang <Jiangyang.Huang@itron.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../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(¶ms_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(¶ms_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 0x0000ffff
#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
#define BRCMF_WSEC_PASSPHRASE BIT(0)
--
1.9.1
^ permalink raw reply related
* [PATCH for-4.14 1/2] brcmfmac: add length check in brcmf_cfg80211_escan_handler()
From: Arend van Spriel @ 2017-09-12 8:47 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel, Kevin Cernekee
In-Reply-To: <1505206074-28781-1-git-send-email-arend.vanspriel@broadcom.com>
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: stable@vger.kernel.org # v4.0.x
Cc: Kevin Cernekee <cernekee@chromium.org>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../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
^ permalink raw reply related
* [PATCH for-4.14 0/2] brcmfmac: scan related fixes
From: Arend van Spriel @ 2017-09-12 8:47 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, 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
^ permalink raw reply
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Arend van Spriel @ 2017-09-12 8:18 UTC (permalink / raw)
To: Kalle Valo
Cc: Kevin Cernekee, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler, Greg KH
In-Reply-To: <87k214ibps.fsf@kamboji.qca.qualcomm.com>
+ Greg KH
On 9/12/2017 10:05 AM, Kalle Valo wrote:
> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
>
>> On 9/12/2017 9:47 AM, Kalle Valo wrote:
>>> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
>>>
>>>> On 9/12/2017 7:48 AM, Kalle Valo wrote:
>>>>> Arend van Spriel <arend.vanspriel@broadcom.com> 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 <mnissler@chromium.org>
>>>>>>> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>>>>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>>>>> ---
>>>>>>> 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: stable@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: stable@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: <stable@vger.kernel.org> # 3.3.x
>>
>> The tag has the meaning of:
>>
>> .. code-block:: none
>>
>> git cherry-pick <this commit>
>>
>> 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
^ permalink raw reply
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Kalle Valo @ 2017-09-12 8:05 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kevin Cernekee, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <59B793C9.2030103@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> On 9/12/2017 9:47 AM, Kalle Valo wrote:
>> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
>>
>>> On 9/12/2017 7:48 AM, Kalle Valo wrote:
>>>> Arend van Spriel <arend.vanspriel@broadcom.com> 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 <mnissler@chromium.org>
>>>>>> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>>>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>>>> ---
>>>>>> 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: stable@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: stable@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: <stable@vger.kernel.org> # 3.3.x
>
> The tag has the meaning of:
>
> .. code-block:: none
>
> git cherry-pick <this commit>
>
> 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
^ permalink raw reply
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Arend van Spriel @ 2017-09-12 7:59 UTC (permalink / raw)
To: Kalle Valo
Cc: Kevin Cernekee, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <87o9qgicju.fsf@kamboji.qca.qualcomm.com>
On 9/12/2017 9:47 AM, Kalle Valo wrote:
> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
>
>> On 9/12/2017 7:48 AM, Kalle Valo wrote:
>>> Arend van Spriel <arend.vanspriel@broadcom.com> 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 <mnissler@chromium.org>
>>>>> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>>> ---
>>>>> 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: stable@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: stable@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: <stable@vger.kernel.org> # 3.3.x
The tag has the meaning of:
.. code-block:: none
git cherry-pick <this commit>
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
^ permalink raw reply
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Kalle Valo @ 2017-09-12 7:47 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kevin Cernekee, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <59B78E94.5040909@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> On 9/12/2017 7:48 AM, Kalle Valo wrote:
>> Arend van Spriel <arend.vanspriel@broadcom.com> 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 <mnissler@chromium.org>
>>>> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>> ---
>>>> 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: stable@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: stable@vger.kernel.org # v3.8+
--
Kalle Valo
^ permalink raw reply
* Re: [V2,3/3] brcmfmac: Add check for short event packets
From: Kalle Valo @ 2017-09-12 7:45 UTC (permalink / raw)
To: Kevin Cernekee
Cc: arend.vanspriel, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <20170909193020.19061-3-cernekee@chromium.org>
Kevin Cernekee <cernekee@chromium.org> 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 <mnissler@chromium.org>
> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
I'll queue this for v4.14 and add:
Cc: stable@vger.kernel.org # v3.8+
--
https://patchwork.kernel.org/patch/9945427/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Arend van Spriel @ 2017-09-12 7:36 UTC (permalink / raw)
To: Kalle Valo
Cc: Kevin Cernekee, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <87tw08mpq1.fsf@purkki.adurom.net>
On 9/12/2017 7:48 AM, Kalle Valo wrote:
> Arend van Spriel <arend.vanspriel@broadcom.com> 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 <mnissler@chromium.org>
>>> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>> ---
>>> 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: stable@vger.kernel.org # v3.8.x
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] mwifiex: check for mfg_mode in add_virtual_intf
From: Kalle Valo @ 2017-09-12 6:03 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, linux-wireless, Cathy Luo, Xinming Hu,
Zhiyuan Yang, James Cao, Mangesh Malusare
In-Reply-To: <20170908194227.GA65107@google.com>
Brian Norris <briannorris@chromium.org> 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
^ permalink raw reply
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Kalle Valo @ 2017-09-12 5:48 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kevin Cernekee, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <deff51ff-40f0-ffa4-afd0-b95465c66a8e@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> 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 <mnissler@chromium.org>
>> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> ---
>> 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?
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH] mwifiex: remove unnecessary call to memset
From: Xinming Hu @ 2017-09-12 1:36 UTC (permalink / raw)
To: Himanshu Jha, amitkarwar@gmail.com
Cc: Nishant Sarmukadam, Ganapathi Bhat, kvalo@codeaurora.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
SGkgSGltYW5zaHUsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBI
aW1hbnNodSBKaGEgW21haWx0bzpoaW1hbnNodWpoYTE5OTY0MEBnbWFpbC5jb21dDQo+IFNlbnQ6
IDIwMTfE6jnUwjExyNUgMjA6NDYNCj4gVG86IGFtaXRrYXJ3YXJAZ21haWwuY29tDQo+IENjOiBO
aXNoYW50IFNhcm11a2FkYW0gPG5pc2hhbnRzQG1hcnZlbGwuY29tPjsgR2FuYXBhdGhpIEJoYXQN
Cj4gPGdiaGF0QG1hcnZlbGwuY29tPjsgWGlubWluZyBIdSA8aHV4bUBtYXJ2ZWxsLmNvbT47DQo+
IGt2YWxvQGNvZGVhdXJvcmEub3JnOyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7DQo+
IG5ldGRldkB2Z2VyLmtlcm5lbC5vcmc7IEhpbWFuc2h1IEpoYSA8aGltYW5zaHVqaGExOTk2NDBA
Z21haWwuY29tPg0KPiBTdWJqZWN0OiBbRVhUXSBbUEFUQ0hdIG13aWZpZXg6IHJlbW92ZSB1bm5l
Y2Vzc2FyeSBjYWxsIHRvIG1lbXNldA0KPiANCj4gRXh0ZXJuYWwgRW1haWwNCj4gDQo+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gY2FsbCB0byBtZW1zZXQgdG8gYXNzaWduIDAgdmFsdWUgaW1tZWRpYXRlbHkg
YWZ0ZXIgYWxsb2NhdGluZyBtZW1vcnkgd2l0aA0KPiBremFsbG9jIGlzIHVubmVjZXNhYXJ5IGFz
IGt6YWxsb2MgYWxsb2NhdGVzIHRoZSBtZW1vcnkgZmlsbGVkIHdpdGggMCB2YWx1ZS4NCj4gDQoN
Ckxvb2tzIGZpbmQgdG8gbWUsIFRoYW5rcy4NCg0KUmVnYXJkcywNClNpbW9uDQoNCj4gU2VtYW50
aWMgcGF0Y2ggdXNlZCB0byByZXNvbHZlIHRoaXMgaXNzdWU6DQo+IA0KPiBAQA0KPiBleHByZXNz
aW9uIGUsZTI7IGNvbnN0YW50IGM7DQo+IHN0YXRlbWVudCBTOw0KPiBAQA0KPiANCj4gICBlID0g
a3phbGxvYyhlMiwgYyk7DQo+ICAgaWYoZSA9PSBOVUxMKSBTDQo+IC0gbWVtc2V0KGUsIDAsIGUy
KTsNCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEhpbWFuc2h1IEpoYSA8aGltYW5zaHVqaGExOTk2NDBA
Z21haWwuY29tPg0KPiAtLS0NCj4gIGRyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmll
eC9zY2FuLmMgfCAyIC0tDQo+ICAxIGZpbGUgY2hhbmdlZCwgMiBkZWxldGlvbnMoLSkNCj4gDQo+
IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvc2Nhbi5j
DQo+IGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3NjYW4uYw0KPiBpbmRl
eCBjOWQ0MWVkLi44ODM4Yjg4IDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9t
YXJ2ZWxsL213aWZpZXgvc2Nhbi5jDQo+ICsrKyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZl
bGwvbXdpZmlleC9zY2FuLmMNCj4gQEAgLTE5MzYsOCArMTkzNiw2IEBAIG13aWZpZXhfYWN0aXZl
X3NjYW5fcmVxX2Zvcl9wYXNzaXZlX2NoYW4oc3RydWN0DQo+IG13aWZpZXhfcHJpdmF0ZSAqcHJp
dikNCj4gIAlpZiAoIXVzZXJfc2Nhbl9jZmcpDQo+ICAJCXJldHVybiAtRU5PTUVNOw0KPiANCj4g
LQltZW1zZXQodXNlcl9zY2FuX2NmZywgMCwgc2l6ZW9mKCp1c2VyX3NjYW5fY2ZnKSk7DQo+IC0N
Cj4gIAlmb3IgKGlkID0gMDsgaWQgPCBNV0lGSUVYX1VTRVJfU0NBTl9DSEFOX01BWDsgaWQrKykg
ew0KPiAgCQlpZiAoIXByaXYtPmhpZGRlbl9jaGFuW2lkXS5jaGFuX251bWJlcikNCj4gIAkJCWJy
ZWFrOw0KPiAtLQ0KPiAyLjcuNA0KDQo=
^ permalink raw reply
* Re: [PATCH 3/3] brcmfmac: Add check for short event packets
From: Arend van Spriel @ 2017-09-11 19:09 UTC (permalink / raw)
To: Mattias Nissler, Kevin Cernekee
Cc: franky.lin, brcm80211-dev-list.pdl, linux-wireless
In-Reply-To: <CAKUbbx+=VpRC0nek=431yxjooun56hb6svSwRjH_faBhdEPf=g@mail.gmail.com>
On 11-09-17 11:19, Mattias Nissler wrote:
> On Fri, Sep 8, 2017 at 9:13 PM, Kevin Cernekee <cernekee@chromium.org> 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 <mnissler@chromium.org>
>> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> 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).
Regards,
Arend
^ permalink raw reply
* QCA6174 fw logs howto
From: Bartosz Chronowski @ 2017-09-11 13:23 UTC (permalink / raw)
To: linux-wireless
Hi everyone,
What are the steps necessary to read QCA6174 firmware logs?
I'm using:
echo 0xffff 0 > /sys/kernel/debug/ieee80211/phy*/ath10k/fw_dbglog
trace-cmd record -e ath10k
trace-cmd report > file
But cannot see fw logs. Are those in binary format in "file" ? If so ,
how to convert them to readible format?
Regards,
BC
^ permalink raw reply
* [PATCH] mwifiex: remove unnecessary call to memset
From: Himanshu Jha @ 2017-09-11 12:46 UTC (permalink / raw)
To: amitkarwar
Cc: nishants, gbhat, huxm, kvalo, linux-wireless, netdev,
Himanshu Jha
call to memset to assign 0 value immediately after allocating
memory with kzalloc is unnecesaary as kzalloc allocates the memory
filled with 0 value.
Semantic patch used to resolve this issue:
@@
expression e,e2; constant c;
statement S;
@@
e = kzalloc(e2, c);
if(e == NULL) S
- memset(e, 0, e2);
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index c9d41ed..8838b88 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1936,8 +1936,6 @@ mwifiex_active_scan_req_for_passive_chan(struct mwifiex_private *priv)
if (!user_scan_cfg)
return -ENOMEM;
- memset(user_scan_cfg, 0, sizeof(*user_scan_cfg));
-
for (id = 0; id < MWIFIEX_USER_SCAN_CHAN_MAX; id++) {
if (!priv->hidden_chan[id].chan_number)
break;
--
2.7.4
^ permalink raw reply related
* Re: [RFC 2/4] mac80211_hwsim: add hwsim_tx_rate_flags to Netlink Attributes
From: Benjamin Beichler @ 2017-09-11 9:49 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1504880794.20347.3.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]
Am 08.09.2017 um 16:26 schrieb Johannes Berg:
> On Fri, 2017-09-08 at 16:11 +0200, Benjamin Beichler wrote:
>> For correct interpretation of a tx rate, the corresponding rate flags
>> are needed (e.g. whether a HT-MCS rate or a legacy rate) and
>> moreover for more correct simulation the other infos of the flags are
>> important (like short-GI). Keeping compability, the flags
>> are not integrated into the existing hwsim_tx_rate, but transmitted
>> as an additional netlink attribute.
> This still exposes a lot of internal detail - perhaps it'd be better to
> convert to some sort of stable rate representation, like in cfg80211?
> Not sure that's sufficient though, it's a bit less detailed.
I don't know what is the problem with the details. The only flag, which
is a bit to verbose is MAC80211_HWSIM_TX_RC_DUP_DATA, which we may
omit. All others describe directly terms used in the IEEE 802.11
standard. Also the representation, that a rate is an MCS-index is quite
good. If you take look here http://mcsindex.com/ , the bitrate would be
not sufficient to get the exact coding and fec rate, therefore you would
also need additional flags. You are right regarding legacy rates, which
are in an encoded table. I tried to decouple internal and external API,
but currently there is no big difference.
Nonetheless the whole hwsim API is highly specialized and only usable
with the linux kernel. Of course the Userland API should be more or less
stable, but the backward compatibility is not touched by this change. As
I already said, this is nearly a fix for hwsim, since currently it's
impossible to differentiate between legacy and MCS-rates, although they
could appear in a single tx_rates array. I think currently minstrel does
not mix HT and legacy rates for data frames, but AFAIK Management/Action
frames are always sent with legacy rates, so there are mixed already.
> johannes
kind regards
Benjamin
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: Benjamin.Beichler@uni-rostock.de
www: http://www.imd.uni-rostock.de/
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5151 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] brcmfmac: Add check for short event packets
From: Mattias Nissler @ 2017-09-11 9:19 UTC (permalink / raw)
To: Kevin Cernekee
Cc: arend.vanspriel, franky.lin, brcm80211-dev-list.pdl,
linux-wireless
In-Reply-To: <20170908191342.28053-4-cernekee@chromium.org>
On Fri, Sep 8, 2017 at 9:13 PM, Kevin Cernekee <cernekee@chromium.org> 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 <mnissler@chromium.org>
> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> 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?
> return;
>
> if (in_interrupt())
> --
> 2.14.1.581.gf28d330327-goog
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox