wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Stefan Wahren]

Hi,

i was able to reproduce an (maybe older issue) with 4-way handshake
offloading for 802.1X in the brcmfmac driver. My setup consists of
Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
Raspberry Pi 3 A+ (Linux 4.19) on AP side. The issue occurs on the STA
side with wpa_supplicant 2.8, which gives the following output:

Configure PMK for driver-based RSN 4-way handshake
EAPOL: Successfully fetched key (len=32)
RSN: Configure PMK for driver-based 4-way handshake - hexdump(len=32):
[REMOVED]
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=5 addr=(nil) key_idx=0
set_tx=0 seq_len=0 key_len=32
nl80211: Set PMK to the driver for b8:27:eb:6c:5e:c9
nl80211: PMK - hexdump(len=32): [REMOVED]
nl80211: Set PMK failed: ret=-22 (Invalid argument)

During this the kernel also gave this warning:

[  874.485374] WARNING: CPU: 0 PID: 460 at
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:5208
brcmf_cfg80211_set_pmk+0x3c/0x58 [brcmfmac]
[  874.504523] Modules linked in: 8021q garp stp mrp llc bcm2835_v4l2(C)
brcmfmac vc4 v4l2_common videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 cec videobuf2_common drm_kms_helper videodev brcmutil
hci_uart cfg80211 mc btbcm drm snd_bcm2835(C) bluetooth smsc95xx
crct10dif_ce usbnet ecdh_generic ecc drm_panel_orientation_quirks
raspberrypi_hwmon rfkill bcm2835_rng bcm2835_thermal pwm_bcm2835
i2c_bcm2835 rng_core vchiq(C) ip_tables x_tables ipv6 nf_defrag_ipv6
[  874.558134] CPU: 0 PID: 460 Comm: wpa_supplicant Tainted: G       
WC        5.2.0-rc4-next-20190614-g65beedb66 #3
[  874.574984] Hardware name: Raspberry Pi 3 Model B (DT)
[  874.586546] pstate: 80000005 (Nzcv daif -PAN -UAO)
[  874.597817] pc : brcmf_cfg80211_set_pmk+0x3c/0x58 [brcmfmac]
[  874.610049] lr : nl80211_set_pmk+0x16c/0x1a8 [cfg80211]
[  874.621776] sp : ffff000011aab910
[  874.631533] x29: ffff000011aab910 x28: ffff80002ec5a000
[  874.643326] x27: 0000000000000014 x26: ffff80002fd9c300
[  874.655094] x25: ffff80002fd9c000 x24: ffff80002ec5c000
[  874.666843] x23: 00000000ffffff95 x22: ffff80002ec5d050
[  874.678580] x21: ffff80002ec5d008 x20: ffff000011aaba30
[  874.690336] x19: ffff000011349000 x18: 0000000000000000
[  874.702080] x17: 0000000000000000 x16: 0000000000000000
[  874.713809] x15: 0000000000000000 x14: be1127680d12277d
[  874.725547] x13: 8ba575fc53793d9f x12: ffff000008dff8a8
[  874.737297] x11: 0000000000000fe0 x10: 0000000000000000
[  874.749059] x9 : ffff000010c12068 x8 : ffff000010c12050
[  874.760832] x7 : ffff000008dfe8c8 x6 : 000000000000003f
[  874.772598] x5 : 0000000000000008 x4 : 000000006ceb27b8
[  874.784349] x3 : ffff000008ef1eb0 x2 : ffff000011aab978
[  874.796091] x1 : 0000000000000000 x0 : ffff80002ec5c7c0
[  874.807853] Call trace:
[  874.816698]  brcmf_cfg80211_set_pmk+0x3c/0x58 [brcmfmac]
[  874.828399]  nl80211_set_pmk+0x16c/0x1a8 [cfg80211]
[  874.839327]  genl_family_rcv_msg+0x364/0x460
[  874.849343]  genl_rcv_msg+0x5c/0xc0
[  874.858282]  netlink_rcv_skb+0x5c/0x128
[  874.867486]  genl_rcv+0x34/0x48
[  874.875956]  netlink_unicast+0x190/0x1f8
[  874.885203]  netlink_sendmsg+0x2cc/0x348
[  874.894397]  sock_sendmsg+0x18/0x30
[  874.903124]  ___sys_sendmsg+0x28c/0x2c8
[  874.912216]  __sys_sendmsg+0x6c/0xc8
[  874.921040]  __arm64_sys_sendmsg+0x20/0x28
[  874.930408]  el0_svc_common.constprop.0+0x64/0x160
[  874.940520]  el0_svc_handler+0x28/0x78
[  874.949552]  el0_svc+0x8/0xc
[  874.957674] ---[ end trace 72f634728d4e750f ]---

Here are the information about the used firmware:

[   11.622355] brcmfmac: brcmf_fw_alloc_request: using
brcm/brcmfmac43430-sdio for chip BCM43430/1
[   11.637498] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available
(err=-2), device may have limited channels available
[   11.658814] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1
wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f

The actual STA configuration can be found here [1] and other report of
this issue here [2].

Any ideas how to fix this?

[1] - https://gist.github.com/lategoodbye/d4b5da60e905cbdf069affbd41cd14ab'
[2] - https://archlinuxarm.org/forum/viewtopic.php?f=60&t=13644

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Stefan Wahren]

Am 15.06.19 um 19:01 schrieb Stefan Wahren:
> Hi,
>
> i was able to reproduce an (maybe older issue) with 4-way handshake
> offloading for 802.1X in the brcmfmac driver. My setup consists of
> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
> Raspberry Pi 3 A+ (Linux 4.19) on AP side.

Looks like Raspberry Pi isn't the only affected platform [3], [4].

[3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
[4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Chi-Hsien Lin]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

(+Stanley)

On 06/16/2019 1:21, Stefan Wahren wrote:
> Am 15.06.19 um 19:01 schrieb Stefan Wahren:
>> Hi,
>>
>> i was able to reproduce an (maybe older issue) with 4-way handshake
>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
> 
> Looks like Raspberry Pi isn't the only affected platform [3], [4].
> 
> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521

Stefan,

Could you please try the attached patch for your wpa_supplicant? We'll 
upstream if it works for you.

Regards,
Chi-hsien Lin

[-- Attachment #2: 0001-wpa_supplicant-Fix-802.1X-4-way-handshake-offload-in.patch --]
[-- Type: text/plain, Size: 1644 bytes --]

From 9774dfbf62f41080267ebb0943015a9f6d1dc0cf Mon Sep 17 00:00:00 2001
From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Date: Mon, 20 May 2019 17:10:39 +0800
Subject: [PATCH] wpa_supplicant: Fix 802.1X 4-way handshake offload indication

Commit d896874f8689 ("nl80211: Indicate 802.1X 4-way handshake
offload in connect") used the req_key_mgmt_offload flag to
indicate to the driver that it should offload the 802.1X handshake.
However, the flag will be updated according to th configuration of
proactive key caching and OKC if key management offload is considered
(it is enabled by default now). Do not update the flag if it has been
set for 802.1X 4-way handshake offload.

Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
---
 wpa_supplicant/wpa_supplicant.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index 96a3691cf3cf..66ee268d861c 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -3221,8 +3221,10 @@ static void wpas_start_assoc_cb(struct wpa_radio_work *work, int deinit)
 	     params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B ||
 	     params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B_192))
 		params.req_key_mgmt_offload = 1;
+	else
+		params.req_key_mgmt_offload = 0;
 
-	if (wpa_s->conf->key_mgmt_offload) {
+	if (wpa_s->conf->key_mgmt_offload && !params.req_key_mgmt_offload) {
 		if (params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X ||
 		    params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SHA256 ||
 		    params.key_mgmt_suite == WPA_KEY_MGMT_IEEE8021X_SUITE_B ||
-- 
2.1.0

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Marcel Holtmann]

Hi Chi-hsien,

>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>> 
>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>> 
>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
> 
> Stefan,
> 
> Could you please try the attached patch for your wpa_supplicant? We'll 
> upstream if it works for you.

I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.

Regards

Marcel

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Chi-Hsien Lin]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]



On 06/17/2019 10:33, Marcel Holtmann wrote:
> Hi Chi-hsien,
> 
>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>
>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>
>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>
>> Stefan,
>>
>> Could you please try the attached patch for your wpa_supplicant? We'll
>> upstream if it works for you.
> 
> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.

Marcel,

This is a kernel warning for invalid application PMK set actions, so the 
fix is to only set PMK to wifi driver when 4-way is offloaded. I think 
Arend added the WARN_ON() intentionally to catch application misuse of 
PMK setting.

You may also remove the warnings with the attached patch, but let's see 
what Arend says first.


Arend,

Any comment?


Regards,
Chi-hsien Lin


> 
> Regards
> 
> Marcel
> 
> .
> 

[-- Attachment #2: 0001-brcmfmac-remove-WARN_ON-for-invalid-pmk-set.patch --]
[-- Type: text/plain, Size: 1896 bytes --]

From a54c0e7dcd815a5ef31bdbabe44792f2cedce0e3 Mon Sep 17 00:00:00 2001
From: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Date: Mon, 17 Jun 2019 23:42:23 -0500
Subject: [PATCH] brcmfmac: remove WARN_ON() for invalid pmk set

2526ff21aa77c("brcmfmac: support 4-way handshake offloading for 802.1X")
added WARN_ON() to catch invalid PMK usage. Remove them and keep the
error return EINVAL.

Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index e9c8b21091a1..08b5fad38307 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1938,7 +1938,7 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev,
 	}
 
 	if (sme->crypto.psk) {
-		if (WARN_ON(profile->use_fwsup != BRCMF_PROFILE_FWSUP_NONE)) {
+		if (profile->use_fwsup != BRCMF_PROFILE_FWSUP_NONE) {
 			err = -EINVAL;
 			goto done;
 		}
@@ -5173,7 +5173,7 @@ static int brcmf_cfg80211_set_pmk(struct wiphy *wiphy, struct net_device *dev,
 
 	/* expect using firmware supplicant for 1X */
 	ifp = netdev_priv(dev);
-	if (WARN_ON(ifp->vif->profile.use_fwsup != BRCMF_PROFILE_FWSUP_1X))
+	if (ifp->vif->profile.use_fwsup != BRCMF_PROFILE_FWSUP_1X)
 		return -EINVAL;
 
 	if (conf->pmk_len > BRCMF_WSEC_MAX_PSK_LEN)
@@ -5189,7 +5189,7 @@ static int brcmf_cfg80211_del_pmk(struct wiphy *wiphy, struct net_device *dev,
 
 	brcmf_dbg(TRACE, "enter\n");
 	ifp = netdev_priv(dev);
-	if (WARN_ON(ifp->vif->profile.use_fwsup != BRCMF_PROFILE_FWSUP_1X))
+	if (ifp->vif->profile.use_fwsup != BRCMF_PROFILE_FWSUP_1X)
 		return -EINVAL;
 
 	return brcmf_set_pmk(ifp, NULL, 0);
-- 
2.1.0

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Arend Van Spriel]

+ Jouni

On 6/18/2019 7:33 AM, Chi-Hsien Lin wrote:
> 
> 
> On 06/17/2019 10:33, Marcel Holtmann wrote:
>> Hi Chi-hsien,
>>
>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>
>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>
>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>
>>> Stefan,
>>>
>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>> upstream if it works for you.
>>
>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
> 
> Marcel,
> 
> This is a kernel warning for invalid application PMK set actions, so the
> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
> Arend added the WARN_ON() intentionally to catch application misuse of
  > PMK setting.
> 
> You may also remove the warnings with the attached patch, but let's see
> what Arend says first.
> 
> 
> Arend,
> 
> Any comment?

Hi Chi-Hsien, Marcel

 From the kernel side I do not see an issue. In order to use 802.1X 
offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in 
NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The 
only improvement would be to document this more clearly in the "WPA/WPA2 
EAPOL handshake offload" DOC section in nl80211.h.

As for the wpa_supplicant behavior it seemed a good idea to reuse the 
req_key_mgmt_offload parameter at the time, but it seems to bite each 
other. Maybe it is better to have a separate flag like 
'req_handshake_offload'. Jouni, any thoughts on this?

Regards,
Arend

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Stefan Wahren]

Hi,

Am 18.06.19 um 10:27 schrieb Arend Van Spriel:
> + Jouni
>
> On 6/18/2019 7:33 AM, Chi-Hsien Lin wrote:
>>
>>
>> On 06/17/2019 10:33, Marcel Holtmann wrote:
>>> Hi Chi-hsien,
>>>
>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA
>>>>>> side and a
>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>
>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>
>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>
>>>> Stefan,
>>>>
>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>> upstream if it works for you.
i've forward this patch to the Arch Linux board hoping someone else has
currently more time.
>>>
>>> I hope that someone is also providing a kernel patch to fix the
>>> issue. Hacking around a kernel issue in userspace is not enough. Fix
>>> the root cause in the kernel.
>>
>> Marcel,
>>
>> This is a kernel warning for invalid application PMK set actions, so the
>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>> Arend added the WARN_ON() intentionally to catch application misuse of
>  > PMK setting.
>>
>> You may also remove the warnings with the attached patch, but let's see
>> what Arend says first.
Instead of removing the WARN_ON i suggest to replace it with a more user
friendly dev_warn().
>>
>>
>> Arend,
>>
>> Any comment?
>
> Hi Chi-Hsien, Marcel
>
> From the kernel side I do not see an issue. In order to use 802.1X
> offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in
> NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted.
> The only improvement would be to document this more clearly in the
> "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.

I missed to add my expectation as a user. At first i assume this new
behavior in wpa_supplicant 2.8 has been tested successful with at least
one Linux wifi driver. So i'm curious if all drivers behave that way?

Another point is that in my wpa_supplicant.conf i never enforced 802.1X
offload and i assume this feature is optional. So can't we do some kind
of fallback in this case?

Stefan

>
> As for the wpa_supplicant behavior it seemed a good idea to reuse the
> req_key_mgmt_offload parameter at the time, but it seems to bite each
> other. Maybe it is better to have a separate flag like
> 'req_handshake_offload'. Jouni, any thoughts on this?
>
> Regards,
> Arend

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Arend Van Spriel]

On 6/18/2019 7:03 PM, Stefan Wahren wrote:
> Hi,
> 
> Am 18.06.19 um 10:27 schrieb Arend Van Spriel:
>> + Jouni
>>
>> On 6/18/2019 7:33 AM, Chi-Hsien Lin wrote:
>>>
>>>
>>> On 06/17/2019 10:33, Marcel Holtmann wrote:
>>>> Hi Chi-hsien,
>>>>
>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA
>>>>>>> side and a
>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>
>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>
>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>
>>>>> Stefan,
>>>>>
>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>> upstream if it works for you.
> i've forward this patch to the Arch Linux board hoping someone else has
> currently more time.
>>>>
>>>> I hope that someone is also providing a kernel patch to fix the
>>>> issue. Hacking around a kernel issue in userspace is not enough. Fix
>>>> the root cause in the kernel.
>>>
>>> Marcel,
>>>
>>> This is a kernel warning for invalid application PMK set actions, so the
>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>> Arend added the WARN_ON() intentionally to catch application misuse of
>>   > PMK setting.
>>>
>>> You may also remove the warnings with the attached patch, but let's see
>>> what Arend says first.
> Instead of removing the WARN_ON i suggest to replace it with a more user
> friendly dev_warn().
>>>
>>>
>>> Arend,
>>>
>>> Any comment?
>>
>> Hi Chi-Hsien, Marcel
>>
>>  From the kernel side I do not see an issue. In order to use 802.1X
>> offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in
>> NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted.
>> The only improvement would be to document this more clearly in the
>> "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
> 
> I missed to add my expectation as a user. At first i assume this new
> behavior in wpa_supplicant 2.8 has been tested successful with at least
> one Linux wifi driver. So i'm curious if all drivers behave that way?

As a matter of fact it has been tested with brcmfmac.

> Another point is that in my wpa_supplicant.conf i never enforced 802.1X
> offload and i assume this feature is optional. So can't we do some kind
> of fallback in this case?

So when the driver indicates it supports the offload, wpa_supplicant opt 
in. There is no possibility for the user to opt out.

Regards,
Arend

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Marcel Holtmann]

Hi Arend,

>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>> 
>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>> 
>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>> 
>>>> Stefan,
>>>> 
>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>> upstream if it works for you.
>>> 
>>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
>> Marcel,
>> This is a kernel warning for invalid application PMK set actions, so the
>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>> Arend added the WARN_ON() intentionally to catch application misuse of
> > PMK setting.
>> You may also remove the warnings with the attached patch, but let's see
>> what Arend says first.
>> Arend,
>> Any comment?
> 
> Hi Chi-Hsien, Marcel
> 
> From the kernel side I do not see an issue. In order to use 802.1X offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.

so nl80211 is an API. And an application can use that API wrongly (be that intentionally or unintentionally), the kernel can not just go WARN_ON and print a backtrace. That is your bug. So please handle wrong user input properly.

Frankly, I don’t get why nl80211 itself is not validating the input and this is left to the driver. I think we need a nl80211 fuzzer that really exercises this API with random values and parameters to provide invalid input.

Regards

Marcel

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Arend Van Spriel]

On 6/19/2019 7:26 AM, Marcel Holtmann wrote:
> Hi Arend,
> 
>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>
>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>
>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>
>>>>> Stefan,
>>>>>
>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>> upstream if it works for you.
>>>>
>>>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
>>> Marcel,
>>> This is a kernel warning for invalid application PMK set actions, so the
>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>> Arend added the WARN_ON() intentionally to catch application misuse of
>>> PMK setting.
>>> You may also remove the warnings with the attached patch, but let's see
>>> what Arend says first.
>>> Arend,
>>> Any comment?
>>
>> Hi Chi-Hsien, Marcel
>>
>>  From the kernel side I do not see an issue. In order to use 802.1X offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
> 
> so nl80211 is an API. And an application can use that API wrongly (be that intentionally or unintentionally), the kernel can not just go WARN_ON and print a backtrace. That is your bug. So please handle wrong user input properly.

Hi Marcel,

You are right. However, the kernel does also return an error if the 
WARN_ON is hit. We can improve by using the EXT_ACK functionality to 
provide more info than just -EINVAL, eg. "PMK not accepted; no 802.1X 
offload requested on connect".

> Frankly, I don’t get why nl80211 itself is not validating the input and this is left to the driver. I think we need a nl80211 fuzzer that really exercises this API with random values and parameters to provide invalid input.

That would mean nl80211 should keep state info between commands. From 
what I remember that has been avoided from day one because of the 
experiences with that in the WEXT days. I welcome any testing be it 
fuzzer or something else.

Regards,
Arend

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Marcel Holtmann]

Hi Arend,

>>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>> 
>>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>> 
>>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>> 
>>>>>> Stefan,
>>>>>> 
>>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>>> upstream if it works for you.
>>>>> 
>>>>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
>>>> Marcel,
>>>> This is a kernel warning for invalid application PMK set actions, so the
>>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>>> Arend added the WARN_ON() intentionally to catch application misuse of
>>>> PMK setting.
>>>> You may also remove the warnings with the attached patch, but let's see
>>>> what Arend says first.
>>>> Arend,
>>>> Any comment?
>>> 
>>> Hi Chi-Hsien, Marcel
>>> 
>>> From the kernel side I do not see an issue. In order to use 802.1X offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
>> so nl80211 is an API. And an application can use that API wrongly (be that intentionally or unintentionally), the kernel can not just go WARN_ON and print a backtrace. That is your bug. So please handle wrong user input properly.
> 
> You are right. However, the kernel does also return an error if the WARN_ON is hit. We can improve by using the EXT_ACK functionality to provide more info than just -EINVAL, eg. "PMK not accepted; no 802.1X offload requested on connect”.

just remove the WARN_ON and replace it with a dev_warn. Userspace should not be able to trigger WARN_ON by using nl80211.

>> Frankly, I don’t get why nl80211 itself is not validating the input and this is left to the driver. I think we need a nl80211 fuzzer that really exercises this API with random values and parameters to provide invalid input.
> 
> That would mean nl80211 should keep state info between commands. From what I remember that has been avoided from day one because of the experiences with that in the WEXT days. I welcome any testing be it fuzzer or something else.

And now driver bugs are bleeding into the API. I expect from a kernel API that it hides driver details. From an userspace program perspective I expect exactly the same input validation and behavior no matter what hardware is used underneath. If we can not do that, then this API has a broken design.

Regards

Marcel

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Stefan Wahren]

Hi Chi-Hsien,

Am 17.06.19 um 10:04 schrieb Chi-Hsien Lin:
> (+Stanley)
>
> On 06/16/2019 1:21, Stefan Wahren wrote:
>> Am 15.06.19 um 19:01 schrieb Stefan Wahren:
>>> Hi,
>>>
>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>
>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
> Stefan,
>
> Could you please try the attached patch for your wpa_supplicant? We'll
> upstream if it works for you.

i tested your wpa_supplicant patch on top of current hostap-2.9-devel.
After applying the patch the driver warning disappeared.

Please take care of the upstream work.

Thanks
Stefan

>
> Regards,
> Chi-hsien Lin