From: Kalle Valo <kvalo@kernel.org>
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
Arnd Bergmann <arnd@arndb.de>
Cc: Duoming Zhou <duoming@zju.edu.cn>,
linux-kernel@vger.kernel.org, konrad.dybcio@linaro.org,
hdegoede@redhat.com, minipli@grsecurity.net,
linux-wireless@vger.kernel.org, brcm80211@lists.linux.dev,
brcm80211-dev-list.pdl@broadcom.com
Subject: Re: [PATCH] wifi: brcmfmac: pcie: handle randbuf allocation failure
Date: Wed, 06 Mar 2024 12:53:57 +0200 [thread overview]
Message-ID: <87h6hjhbqy.fsf@kernel.org> (raw)
In-Reply-To: <fdaefac9-1d02-4424-b893-4306b97028ca@broadcom.com> (Arend van Spriel's message of "Wed, 6 Mar 2024 10:19:58 +0100")
Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> On 3/1/2024 2:51 PM, Duoming Zhou wrote:
>> The kzalloc() in brcmf_pcie_download_fw_nvram() will return
>> null if the physical memory has run out. As a result, if we
>> use get_random_bytes() to generate random bytes in the randbuf,
>> the null pointer dereference bug will happen.
>> Return -ENOMEM from brcmf_pcie_download_fw_nvram() if kzalloc()
>> fails for randbuf.
>> Fixes: 91918ce88d9f ("wifi: brcmfmac: pcie: Provide a buffer of
>> random bytes to the device")
>
> Looks good to me. Looking for kernel guideline about stack usage to
> determine whether it would be ok to just use buffer on stack. Does
> anyone know. This one is 256 bytes so I guess the allocation is
> warranted here.
Arnd, what do you suggest? Do we have any documentation or guidelines
anywhere?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-03-06 10:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 13:51 [PATCH] wifi: brcmfmac: pcie: handle randbuf allocation failure Duoming Zhou
2024-03-06 9:19 ` Arend van Spriel
2024-03-06 10:53 ` Kalle Valo [this message]
2024-03-06 11:07 ` Arnd Bergmann
2024-03-06 12:53 ` Arend van Spriel
2024-03-06 14:11 ` duoming
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=87h6hjhbqy.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=arend.vanspriel@broadcom.com \
--cc=arnd@arndb.de \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211@lists.linux.dev \
--cc=duoming@zju.edu.cn \
--cc=hdegoede@redhat.com \
--cc=konrad.dybcio@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=minipli@grsecurity.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.