Linux wireless drivers development
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Duoming Zhou <duoming@zju.edu.cn>, linux-kernel@vger.kernel.org
Cc: kvalo@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, 6 Mar 2024 10:19:58 +0100	[thread overview]
Message-ID: <fdaefac9-1d02-4424-b893-4306b97028ca@broadcom.com> (raw)
In-Reply-To: <20240301135134.29577-1-duoming@zju.edu.cn>

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

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.

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index d7fb88bb6ae..5ab9c902e49 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -1730,6 +1730,8 @@ static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo,
>   
>   			address -= rand_len;
>   			randbuf = kzalloc(rand_len, GFP_KERNEL);
> +			if (!randbuf)
> +				return -ENOMEM;
>   			get_random_bytes(randbuf, rand_len);
>   			memcpy_toio(devinfo->tcm + address, randbuf, rand_len);
>   			kfree(randbuf);

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

  reply	other threads:[~2024-03-06  9:20 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 [this message]
2024-03-06 10:53   ` Kalle Valo
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=fdaefac9-1d02-4424-b893-4306b97028ca@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --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=kvalo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox