Re: [PATCH v3 4/5] brcmfmac: Update SSID of hidden AP while informing its bss to cfg80211 layer

[Kalle Valo <kvalo@kernel.org>]

"Lin Ian (CSSITB CSS ICW SW WFS / EE)" <ian.lin@infineon.com> writes:

> On 9/28/2022 6:07 PM, Lin Ian (CSSITB CSS ICW SW WFS / EE) wrote:
>>
>>
>> On 9/28/2022 2:38 PM, Kalle Valo wrote:
>>> Caution: This e-mail originated outside Infineon Technologies. Do
>>> not click on links or open attachments unless you validate it is
>>> safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx>.
>>>
>>>
>>>
>>> Ian Lin <ian.lin@infineon.com> writes:
>>>
>>>> From: Syed Rafiuddeen <syed.rafiuddeen@cypress.com>
>>>>
>>>> cfg80211 layer on DUT STA is disconnecting ongoing connection
>>>> attempt after
>>>> receiving association response, because cfg80211 layer does not
>>>> have valid
>>>> AP bss information. On association response event, brcmfmac
>>>> communicates
>>>> the AP bss information to cfg80211 layer, but SSID seem to be
>>>> empty in AP
>>>> bss information, and cfg80211 layer prints kernel warning and then
>>>> disconnects the ongoing connection attempt.
>>>>
>>>> SSID is empty in SSID IE, but 'bi->SSID' contains a valid SSID, so
>>>> updating the SSID for hidden AP while informing its bss information
>>>> to cfg80211 layer.
>>>>
>>>> Signed-off-by: Syed Rafiuddeen <syed.rafiuddeen@cypress.com>
>>>> Signed-off-by: Chung-Hsien Hsu <chung-hsien.hsu@infineon.com>
>>>> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@infineon.com>
>>>> Signed-off-by: Ian Lin <ian.lin@infineon.com>
>>>> ---
>>>>   .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c   | 8
>>>> ++++++++
>>>>   1 file changed, 8 insertions(+)
>>>>
>>>> diff --git
>>>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>> index 6c37da42e61b..3560afe0ccfe 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>>>> @@ -3003,6 +3003,7 @@ static s32 brcmf_inform_single_bss(struct
>>>> brcmf_cfg80211_info *cfg,
>>>>        u8 *notify_ie;
>>>>        size_t notify_ielen;
>>>>        struct cfg80211_inform_bss bss_data = {};
>>>> +     struct brcmf_tlv *ssid;
>>>>
>>>>        if (le32_to_cpu(bi->length) > WL_BSS_INFO_MAX) {
>>>>                bphy_err(drvr, "Bss info is larger than buffer.
>>>> Discarding\n");
>>>> @@ -3032,6 +3033,13 @@ static s32 brcmf_inform_single_bss(struct
>>>> brcmf_cfg80211_info *cfg,
>>>>        notify_ielen = le32_to_cpu(bi->ie_length);
>>>>        bss_data.signal = (s16)le16_to_cpu(bi->RSSI) * 100;
>>>>
>>>> +     ssid = (struct brcmf_tlv *)
>>>> +             brcmf_parse_tlvs(notify_ie, notify_ielen, WLAN_EID_SSID);
>>> This still casts away the const. For some reason brcmf_parse_tlvs()
>>> takes a const buffer:
>>>
>>> static const struct brcmf_tlv *brcmf_parse_tlvs(const void *buf,
>>> int buflen, uint key)
>>>
>>> I'm not familiar with brcmfmac internal so I don't know why it does
>>> that, but that means the buffer cannot be modified. If you need to
>>> modify the ssid should you make a copy of it?
>>
>> In brcmf_parse_tlvs(const void *buf, int buflen, uint key),
>> it will find the key in buf and return the address of this key, as
>> the return pointer.
>> This function don't intend caller to modify content of buf in most
>> cases, so it defines a const return pointer.
>> But in this case, it just need to do it, so I need the typecast here.
>
> Do you accept the typecast here?

To me writing a const data is wrong. IIRC it was something like six
months ago that rtw89 was also writing a const variable and it caused a
crash because the memory was in a read-only area (or something like
that).

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches