From: samasth.norway.ananda@oracle.com
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
Kalle Valo <kvalo@kernel.org>
Cc: linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>
Subject: Re: [External] : Re: Buffer overrun error found in brcm80211 driver code
Date: Wed, 8 May 2024 16:27:36 -0700 [thread overview]
Message-ID: <667bb700-1cef-4969-85e7-cf2e9e5be7c2@oracle.com> (raw)
In-Reply-To: <c8d8ac40-d4d5-417b-a67a-8b1fb016d2ca@broadcom.com>
On 5/7/24 12:09 PM, Arend van Spriel wrote:
> - moved John to Cc: as he passed the wireless maintainer role to Kalle
> long ago.
>
> On 5/6/2024 9:03 PM, samasth.norway.ananda@oracle.com wrote:
>> Hi,
>>
>>
>> I came across an issue reported by an internal static analysis tool
>> when tested on the code for brcm80211 driver.
>>
>> The commit which introduced is -
>> 5b435de0d786869c95d1962121af0d7df2542009
>> ("net: wireless: add brcm80211 drivers")
>>
>>
>> In the file -
>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
>>
>> within the function wlc_lcnphy_tx_iqlo_cal()
>>
>> we assign value to band_idx as below
>> band_idx = (CHSPEC_IS5G(pi->radio_chanspec) ? 1 : 0);
>> From this band_idx could be either 1 or 0.
>>
>> But when we look at the array iqcal_gainparams_numgains_lcnphy[] at
>> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
>>
>> We can notice that it is initialized with only one value in it.
>>
>> static const u16 iqcal_gainparams_numgains_lcnphy[1] = {
>> ARRAY_SIZE(tbl_iqcal_gainparams_lcnphy_2G),
>> };
>>
>>
>> So, when we try to access iqcal_gainparams_numgains_lcnphy[band_idx]
>> within the for loop in the same function we could be reading a wrong
>> value of iqcal_gainparams_numgains_lcnphy[1]
>>
>> Do you have any suggestion on how we can resolve this?
>> Is it possible to keep band_idx to just 0?
>
> Hi Samasth,
>
> Did some digging through the code and the only device for which the LCN
> phy code is used is the BCM4313 which is a 2G-only device. Hence the
> band_idx in the code you pointed out will never be 1. My suggestion
> would be to get rid on band_idx and always use 0 instead and add:
>
> if (WARN_ON(CHSPEC_IS5G(pi->radio_chanspec)))
> return;
>
> before the kmalloc_array() call at the beginning of the function.
Thanks for looking into it Arend.
I will work on a patch and make the changes as you suggested. Will send
it out for review soon.
Samasth.
>
> Regards,
> Arend
prev parent reply other threads:[~2024-05-08 23:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 19:03 Buffer overrun error found in brcm80211 driver code samasth.norway.ananda
2024-05-07 19:09 ` Arend van Spriel
2024-05-08 23:27 ` samasth.norway.ananda [this message]
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=667bb700-1cef-4969-85e7-cf2e9e5be7c2@oracle.com \
--to=samasth.norway.ananda@oracle.com \
--cc=arend.vanspriel@broadcom.com \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).