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
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
(+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
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
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
>
> .
>
+ 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
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
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
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
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
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
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