From: Marcel Holtmann <marcel@holtmann.org>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: Chi-Hsien Lin <Chi-Hsien.Lin@cypress.com>,
Stefan Wahren <wahrenst@gmx.net>,
Stanley Hsu <Stanley.Hsu@cypress.com>,
Franky Lin <franky.lin@broadcom.com>,
Hante Meuleman <hante.meuleman@broadcom.com>,
Wright Feng <Wright.Feng@cypress.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"brcm80211-dev-list.pdl@broadcom.com"
<brcm80211-dev-list.pdl@broadcom.com>,
brcm80211-dev-list <brcm80211-dev-list@cypress.com>,
Jouni Malinen <j@w1.fi>
Subject: Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
Date: Thu, 20 Jun 2019 20:39:10 +0200 [thread overview]
Message-ID: <D3FC6B1E-ABC8-408E-8CAD-75F1D5BA8469@holtmann.org> (raw)
In-Reply-To: <a65a9b67-8307-12d0-9ef7-94bd2eb5badf@broadcom.com>
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
next prev parent reply other threads:[~2019-06-20 18:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-15 17:01 wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk Stefan Wahren
2019-06-15 17:21 ` Stefan Wahren
2019-06-17 8:04 ` Chi-Hsien Lin
2019-06-17 14:33 ` Marcel Holtmann
2019-06-18 5:33 ` Chi-Hsien Lin
2019-06-18 8:27 ` Arend Van Spriel
2019-06-18 17:03 ` Stefan Wahren
2019-06-20 9:44 ` Arend Van Spriel
2019-06-19 5:26 ` Marcel Holtmann
2019-06-20 10:04 ` Arend Van Spriel
2019-06-20 18:39 ` Marcel Holtmann [this message]
2019-06-20 18:01 ` Stefan Wahren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D3FC6B1E-ABC8-408E-8CAD-75F1D5BA8469@holtmann.org \
--to=marcel@holtmann.org \
--cc=Chi-Hsien.Lin@cypress.com \
--cc=Stanley.Hsu@cypress.com \
--cc=Wright.Feng@cypress.com \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211-dev-list@cypress.com \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=j@w1.fi \
--cc=linux-wireless@vger.kernel.org \
--cc=wahrenst@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).