AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly.
Signed-off-by: David Lin yu-hao.lin@nxp.com Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers") Cc: stable@vger.kernel.org
---
v2: - v1 was a not finished patch that was send to the LKML by mistake --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++ drivers/net/wireless/marvell/mwifiex/fw.h | 1 + drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 + drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++++++ 4 files changed, 12 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 7a15ea8072e6..3604abcbcff9 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -2047,6 +2047,8 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
mwifiex_set_sys_config_invalid_data(bss_cfg);
+ memcpy(bss_cfg->mac_addr, priv->curr_addr, ETH_ALEN); + if (params->beacon_interval) bss_cfg->beacon_period = params->beacon_interval; if (params->dtim_period) diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h index 8e6db904e5b2..62f3c9a52a1d 100644 --- a/drivers/net/wireless/marvell/mwifiex/fw.h +++ b/drivers/net/wireless/marvell/mwifiex/fw.h @@ -165,6 +165,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER { #define TLV_TYPE_STA_MAC_ADDR (PROPRIETARY_TLV_BASE_ID + 32) #define TLV_TYPE_BSSID (PROPRIETARY_TLV_BASE_ID + 35) #define TLV_TYPE_CHANNELBANDLIST (PROPRIETARY_TLV_BASE_ID + 42) +#define TLV_TYPE_UAP_MAC_ADDRESS (PROPRIETARY_TLV_BASE_ID + 43) #define TLV_TYPE_UAP_BEACON_PERIOD (PROPRIETARY_TLV_BASE_ID + 44) #define TLV_TYPE_UAP_DTIM_PERIOD (PROPRIETARY_TLV_BASE_ID + 45) #define TLV_TYPE_UAP_BCAST_SSID (PROPRIETARY_TLV_BASE_ID + 48) diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h b/drivers/net/wireless/marvell/mwifiex/ioctl.h index 091e7ca79376..e8825f302de8 100644 --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h @@ -107,6 +107,7 @@ struct mwifiex_uap_bss_param { u8 qos_info; u8 power_constraint; struct mwifiex_types_wmm_info wmm_info; + u8 mac_addr[ETH_ALEN]; };
enum { diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c index e78a201cd150..491e36611909 100644 --- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c +++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c @@ -468,6 +468,7 @@ void mwifiex_config_uap_11d(struct mwifiex_private *priv, static int mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) { + struct host_cmd_tlv_mac_addr *mac_tlv; struct host_cmd_tlv_dtim_period *dtim_period; struct host_cmd_tlv_beacon_period *beacon_period; struct host_cmd_tlv_ssid *ssid; @@ -487,6 +488,13 @@ mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) int i; u16 cmd_size = *param_size;
+ mac_tlv = (struct host_cmd_tlv_mac_addr *)tlv; + mac_tlv->header.type = cpu_to_le16(TLV_TYPE_UAP_MAC_ADDRESS); + mac_tlv->header.len = cpu_to_le16(ETH_ALEN); + memcpy(mac_tlv->mac_addr, bss_cfg->mac_addr, ETH_ALEN); + cmd_size += sizeof(struct host_cmd_tlv_mac_addr); + tlv += sizeof(struct host_cmd_tlv_mac_addr); + if (bss_cfg->ssid.ssid_len) { ssid = (struct host_cmd_tlv_ssid *)tlv; ssid->header.type = cpu_to_le16(TLV_TYPE_UAP_SSID);
base-commit: 783004b6dbda2cfe9a552a4cc9c1d168a2068f6c
On Sat, Dec 09, 2023 at 07:41:27AM +0800, David Lin wrote:
AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly.
Signed-off-by: David Lin yu-hao.lin@nxp.com Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers") Cc: stable@vger.kernel.org
Reviewed-by: Francesco Dolcini francesco.dolcini@toradex.com
Francesco
On 08/12/2023 20:41, David Lin wrote:
AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly.
Signed-off-by: David Lin yu-hao.lin@nxp.com Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers") Cc: stable@vger.kernel.org
v2: - v1 was a not finished patch that was send to the LKML by mistake
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++ drivers/net/wireless/marvell/mwifiex/fw.h | 1 + drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 + drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++++++ 4 files changed, 12 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 7a15ea8072e6..3604abcbcff9 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -2047,6 +2047,8 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy, mwifiex_set_sys_config_invalid_data(bss_cfg);
- memcpy(bss_cfg->mac_addr, priv->curr_addr, ETH_ALEN);
- if (params->beacon_interval) bss_cfg->beacon_period = params->beacon_interval; if (params->dtim_period)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h index 8e6db904e5b2..62f3c9a52a1d 100644 --- a/drivers/net/wireless/marvell/mwifiex/fw.h +++ b/drivers/net/wireless/marvell/mwifiex/fw.h @@ -165,6 +165,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER { #define TLV_TYPE_STA_MAC_ADDR (PROPRIETARY_TLV_BASE_ID + 32) #define TLV_TYPE_BSSID (PROPRIETARY_TLV_BASE_ID + 35) #define TLV_TYPE_CHANNELBANDLIST (PROPRIETARY_TLV_BASE_ID + 42) +#define TLV_TYPE_UAP_MAC_ADDRESS (PROPRIETARY_TLV_BASE_ID + 43) #define TLV_TYPE_UAP_BEACON_PERIOD (PROPRIETARY_TLV_BASE_ID + 44) #define TLV_TYPE_UAP_DTIM_PERIOD (PROPRIETARY_TLV_BASE_ID + 45) #define TLV_TYPE_UAP_BCAST_SSID (PROPRIETARY_TLV_BASE_ID + 48) diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h b/drivers/net/wireless/marvell/mwifiex/ioctl.h index 091e7ca79376..e8825f302de8 100644 --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h @@ -107,6 +107,7 @@ struct mwifiex_uap_bss_param { u8 qos_info; u8 power_constraint; struct mwifiex_types_wmm_info wmm_info;
- u8 mac_addr[ETH_ALEN]; };
enum { diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c index e78a201cd150..491e36611909 100644 --- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c +++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c @@ -468,6 +468,7 @@ void mwifiex_config_uap_11d(struct mwifiex_private *priv, static int mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) {
- struct host_cmd_tlv_mac_addr *mac_tlv; struct host_cmd_tlv_dtim_period *dtim_period; struct host_cmd_tlv_beacon_period *beacon_period; struct host_cmd_tlv_ssid *ssid;
@@ -487,6 +488,13 @@ mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) int i; u16 cmd_size = *param_size;
- mac_tlv = (struct host_cmd_tlv_mac_addr *)tlv;
- mac_tlv->header.type = cpu_to_le16(TLV_TYPE_UAP_MAC_ADDRESS);
- mac_tlv->header.len = cpu_to_le16(ETH_ALEN);
- memcpy(mac_tlv->mac_addr, bss_cfg->mac_addr, ETH_ALEN);
- cmd_size += sizeof(struct host_cmd_tlv_mac_addr);
- tlv += sizeof(struct host_cmd_tlv_mac_addr);
- if (bss_cfg->ssid.ssid_len) { ssid = (struct host_cmd_tlv_ssid *)tlv; ssid->header.type = cpu_to_le16(TLV_TYPE_UAP_SSID);
base-commit: 783004b6dbda2cfe9a552a4cc9c1d168a2068f6c
Tested-by: Rafael Beims rafael.beims@toradex.com # Verdin iMX8MP / SD8997 SD
Rafael
Hi,
Nitpick: "fix STA cannot connect to AP" isn't the best commit message; that could describe an enormous number of fixes. Maybe something more like "Configure BSSID consistently when starting AP"?
On Sat, Dec 09, 2023 at 07:41:27AM +0800, David Lin wrote:
AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and net interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly.
Signed-off-by: David Lin yu-hao.lin@nxp.com Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers") Cc: stable@vger.kernel.org
v2:
- v1 was a not finished patch that was send to the LKML by mistake
Looks fine to me:
Acked-by: Brian Norris briannorris@chromium.org
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++ drivers/net/wireless/marvell/mwifiex/fw.h | 1 + drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 + drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++++++ 4 files changed, 12 insertions(+)
--- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c +++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
@@ -487,6 +488,13 @@ mwifiex_uap_bss_param_prepare(u8 *tlv, void *cmd_buf, u16 *param_size) int i; u16 cmd_size = *param_size;
- mac_tlv = (struct host_cmd_tlv_mac_addr *)tlv;
Not directly related to this patch, but while you're expanding the size of this command buffer: it always felt like a security-hole-in-waiting that none of these command producers do any kinds of bounds checking. We're just "lucky" that these function only generate contents of ~100 bytes at max, while MWIFIEX_SIZE_OF_CMD_BUFFER=2048. But, just add a few more user-space controlled TLV params, and boom, we'll have ourselves a nice little CVE.
It probably wouldn't hurt to significantly write much of this driver, but at a minimum, we could probably use a few checks like this:
cmd_size += sizeof(struct host_cmd_tlv_mac_addr); if (cmd_size > MWIFIEX_SIZE_OF_CMD_BUFFER) return -1; // Only touch tlv *after* the bounds check.
That doesn't need to block this patch, of course.
Brian
- mac_tlv->header.type = cpu_to_le16(TLV_TYPE_UAP_MAC_ADDRESS);
- mac_tlv->header.len = cpu_to_le16(ETH_ALEN);
- memcpy(mac_tlv->mac_addr, bss_cfg->mac_addr, ETH_ALEN);
- cmd_size += sizeof(struct host_cmd_tlyyv_mac_addr);
- tlv += sizeof(struct host_cmd_tlv_mac_addr);
- if (bss_cfg->ssid.ssid_len) { ssid = (struct host_cmd_tlv_ssid *)tlv; ssid->header.type = cpu_to_le16(TLV_TYPE_UAP_SSID);
base-commit: 783004b6dbda2cfe9a552a4cc9c1d168a2068f6c
2.25.1
From: Brian Norris briannorris@chromium.org Sent: Thursday, December 14, 2023 10:08 AM To: David Lin yu-hao.lin@nxp.com Cc: linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh tsung-hsien.hsieh@nxp.com; stable@vger.kernel.org Subject: [EXT] Re: [PATCH v2] wifi: mwifiex: fix STA cannot connect to AP
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
Hi,
Nitpick: "fix STA cannot connect to AP" isn't the best commit message; that could describe an enormous number of fixes. Maybe something more like "Configure BSSID consistently when starting AP"?
Thanks for your suggestion. I will change commit message as you suggested. Does it mean I should create another patch from v1?
On Sat, Dec 09, 2023 at 07:41:27AM +0800, David Lin wrote:
AP BSSID configuration is missing at AP start. Without this fix, FW returns STA interface MAC address after first init. When hostapd restarts, it gets MAC address from netdev before driver sets STA MAC to netdev again. Now MAC address between hostapd and
net
interface are different causes STA cannot connect to AP. After that MAC address of uap0 mlan0 become the same. And issue disappears after following hostapd restart (another issue is AP/STA MAC address become the same). This patch fixes the issue cleanly.
Signed-off-by: David Lin yu-hao.lin@nxp.com Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers") Cc: stable@vger.kernel.org
v2:
- v1 was a not finished patch that was send to the LKML by mistake
Looks fine to me:
Acked-by: Brian Norris briannorris@chromium.org
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++ drivers/net/wireless/marvell/mwifiex/fw.h | 1 + drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 + drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++++++ 4 files changed, 12 insertions(+)
--- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c +++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
@@ -487,6 +488,13 @@ mwifiex_uap_bss_param_prepare(u8 *tlv, void
*cmd_buf, u16 *param_size)
int i; u16 cmd_size = *param_size;
mac_tlv = (struct host_cmd_tlv_mac_addr *)tlv;Not directly related to this patch, but while you're expanding the size of this command buffer: it always felt like a security-hole-in-waiting that none of these command producers do any kinds of bounds checking. We're just "lucky" that these function only generate contents of ~100 bytes at max, while MWIFIEX_SIZE_OF_CMD_BUFFER=2048. But, just add a few more user-space controlled TLV params, and boom, we'll have ourselves a nice little CVE.
It probably wouldn't hurt to significantly write much of this driver, but at a minimum, we could probably use a few checks like this:
cmd_size += sizeof(struct host_cmd_tlv_mac_addr); if (cmd_size > MWIFIEX_SIZE_OF_CMD_BUFFER) return -1; // Only touch tlv *after* the bounds check.That doesn't need to block this patch, of course.
Brian
I will modify the code for next patch.
David
mac_tlv->header.type =cpu_to_le16(TLV_TYPE_UAP_MAC_ADDRESS);
mac_tlv->header.len = cpu_to_le16(ETH_ALEN);memcpy(mac_tlv->mac_addr, bss_cfg->mac_addr, ETH_ALEN);cmd_size += sizeof(struct host_cmd_tlyyv_mac_addr);tlv += sizeof(struct host_cmd_tlv_mac_addr);if (bss_cfg->ssid.ssid_len) { ssid = (struct host_cmd_tlv_ssid *)tlv; ssid->header.type = cpu_to_le16(TLV_TYPE_UAP_SSID);base-commit: 783004b6dbda2cfe9a552a4cc9c1d168a2068f6c
2.25.1
Hello David,
On Thu, Dec 14, 2023 at 02:22:57AM +0000, David Lin wrote:
From: Brian Norris briannorris@chromium.org
...
Nitpick: "fix STA cannot connect to AP" isn't the best commit message; that could describe an enormous number of fixes. Maybe something more like "Configure BSSID consistently when starting AP"?
Thanks for your suggestion. I will change commit message as you suggested. Does it mean I should create another patch from v1?
Just create `[PATCH v3] wifi: mwifiex: fix STA cannot connect to AP`
Add the change suggested by Brian and the tags you received on this v2:
- Reviewed-by: Francesco Dolcini francesco.dolcini@toradex.com - Tested-by: Rafael Beims rafael.beims@toradex.com # Verdin iMX8MP / SD8997 SD - Acked-by: Brian Norris briannorris@chromium.org
Not directly related to this patch, but while you're expanding the size of this command buffer: it always felt like a security-hole-in-waiting that none of these command producers do any kinds of bounds checking. We're just "lucky" that these function only generate contents of ~100 bytes at max, while MWIFIEX_SIZE_OF_CMD_BUFFER=2048. But, just add a few more user-space controlled TLV params, and boom, we'll have ourselves a nice little CVE.
It probably wouldn't hurt to significantly write much of this driver, but at a minimum, we could probably use a few checks like this:
cmd_size += sizeof(struct host_cmd_tlv_mac_addr); if (cmd_size > MWIFIEX_SIZE_OF_CMD_BUFFER) return -1; // Only touch tlv *after* the bounds check.That doesn't need to block this patch, of course.
Brian
I will modify the code for next patch.
I would suggest not modify this in this patch, we should fix all the code that is subjected to this potential issue.
I would personally do a follow-up patch just to add the check to avoid overflowing the cmd buffer everywhere it is used.
Francesco
From: Francesco Dolcini francesco@dolcini.it Sent: Thursday, December 14, 2023 3:35 PM To: David Lin yu-hao.lin@nxp.com Cc: Brian Norris briannorris@chromium.org; linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh tsung-hsien.hsieh@nxp.com; stable@vger.kernel.org Subject: Re: [EXT] Re: [PATCH v2] wifi: mwifiex: fix STA cannot connect to AP
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
Hello David,
On Thu, Dec 14, 2023 at 02:22:57AM +0000, David Lin wrote:
From: Brian Norris briannorris@chromium.org
...
Nitpick: "fix STA cannot connect to AP" isn't the best commit message; that could describe an enormous number of fixes. Maybe something more like "Configure BSSID consistently when starting AP"?
Thanks for your suggestion. I will change commit message as you suggested. Does it mean I should create another patch from v1?
Just create `[PATCH v3] wifi: mwifiex: fix STA cannot connect to AP`
Add the change suggested by Brian and the tags you received on this v2:
- Reviewed-by: Francesco Dolcini francesco.dolcini@toradex.com
- Tested-by: Rafael Beims rafael.beims@toradex.com # Verdin iMX8MP /
SD8997 SD
- Acked-by: Brian Norris briannorris@chromium.org
O.K. Thanks.
Not directly related to this patch, but while you're expanding the size of this command buffer: it always felt like a security-hole-in-waiting that none of these command producers do any
kinds of bounds checking.
We're just "lucky" that these function only generate contents of ~100 bytes at max, while MWIFIEX_SIZE_OF_CMD_BUFFER=2048. But, just add a few more user-space controlled TLV params, and boom, we'll have ourselves a nice little CVE.
It probably wouldn't hurt to significantly write much of this driver, but at a minimum, we could probably use a few checks like this:
cmd_size += sizeof(struct host_cmd_tlv_mac_addr); if (cmd_size > MWIFIEX_SIZE_OF_CMD_BUFFER) return -1; // Only touch tlv *after* the bounds check.That doesn't need to block this patch, of course.
Brian
I will modify the code for next patch.
I would suggest not modify this in this patch, we should fix all the code that is subjected to this potential issue.
I would personally do a follow-up patch just to add the check to avoid overflowing the cmd buffer everywhere it is used.
Francesco
O.K. I will only change commit message. In fact, this TLV command is added as the first one command.
On Thu, Dec 14, 2023 at 3:38 AM David Lin yu-hao.lin@nxp.com wrote:
From: Francesco Dolcini francesco@dolcini.it
On Thu, Dec 14, 2023 at 02:22:57AM +0000, David Lin wrote:
From: Brian Norris briannorris@chromium.org It probably wouldn't hurt to significantly write much of this driver, but at a minimum, we could probably use a few checks like this:
cmd_size += sizeof(struct host_cmd_tlv_mac_addr); if (cmd_size > MWIFIEX_SIZE_OF_CMD_BUFFER) return -1; // Only touch tlv *after* the bounds check.That doesn't need to block this patch, of course.
Brian
I will modify the code for next patch.
I would suggest not modify this in this patch, we should fix all the code that is subjected to this potential issue.
I would personally do a follow-up patch just to add the check to avoid overflowing the cmd buffer everywhere it is used.
Right, there's tons of code that could potentially be affected, and this is definitely a separate patch. (Your feature only adds on to the existing issue, so these are separate logical changes.)
O.K. I will only change commit message. In fact, this TLV command is added as the first one command.
Well, it doesn't really matter than your TLV is "first" -- if there's an overflow, there's an overflow. Maybe the 8 bytes you're adding here are the necessary tipping point. I don't know without doing some kind of informal mathematics/proof.
Brian
From: Brian Norris briannorris@chromium.org Sent: Friday, December 15, 2023 2:52 AM To: David Lin yu-hao.lin@nxp.com Cc: Francesco Dolcini francesco@dolcini.it; linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; kvalo@kernel.org; Pete Hsieh tsung-hsien.hsieh@nxp.com; stable@vger.kernel.org Subject: Re: [EXT] Re: [PATCH v2] wifi: mwifiex: fix STA cannot connect to AP
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
On Thu, Dec 14, 2023 at 3:38 AM David Lin yu-hao.lin@nxp.com wrote:
From: Francesco Dolcini francesco@dolcini.it
On Thu, Dec 14, 2023 at 02:22:57AM +0000, David Lin wrote:
From: Brian Norris briannorris@chromium.org It probably wouldn't hurt to significantly write much of this driver, but at a minimum, we could probably use a few checks like this:
cmd_size += sizeof(struct host_cmd_tlv_mac_addr); if (cmd_size > MWIFIEX_SIZE_OF_CMD_BUFFER) return -1; // Only touch tlv *after* the bounds check.That doesn't need to block this patch, of course.
Brian
I will modify the code for next patch.
I would suggest not modify this in this patch, we should fix all the code that is subjected to this potential issue.
I would personally do a follow-up patch just to add the check to avoid overflowing the cmd buffer everywhere it is used.
Right, there's tons of code that could potentially be affected, and this is definitely a separate patch. (Your feature only adds on to the existing issue, so these are separate logical changes.)
O.K. I will only change commit message. In fact, this TLV command is added
as the first one command.
Well, it doesn't really matter than your TLV is "first" -- if there's an overflow, there's an overflow. Maybe the 8 bytes you're adding here are the necessary tipping point. I don't know without doing some kind of informal mathematics/proof.
Brian
Understood. Thanks.
linux-stable-mirror@lists.linaro.org
-
Brian Norris -
David Lin -
Francesco Dolcini -
Rafael Beims