[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <224867b0.cdd3.18e141ac13c.Coremail.duoming@zju.edu.cn>
Date: Wed, 6 Mar 2024 22:11:21 +0800 (GMT+08:00)
From: duoming@....edu.cn
To: "Arend van Spriel" <arend.vanspriel@...adcom.com>
Cc: "Arnd Bergmann" <arnd@...db.de>, "Kalle Valo" <kvalo@...nel.org>,
linux-kernel@...r.kernel.org,
"Konrad Dybcio" <konrad.dybcio@...aro.org>,
"Hans de Goede" <hdegoede@...hat.com>, minipli@...ecurity.net,
linux-wireless@...r.kernel.org, brcm80211@...ts.linux.dev,
brcm80211-dev-list.pdl@...adcom.com
Subject: Re: [PATCH] wifi: brcmfmac: pcie: handle randbuf allocation failure
On Wed, 6 Mar 2024 13:53:19 +0100 Arend van Spriel 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?
> >
> > I don't think we have anything document about this. I usually
> > consider anything more than half a kilobyte as excessive,
> > even though the warning limit is higher.
> >
> > 256 bytes is usually fine, but in this case I would split out
> > the basic block that does this into a separate function
> > so it does not share the stack frame with other leaf functions
> > below brcmf_pcie_download_fw_nvram(). It might also be justified
> > to then mark it as noinline_for_stack.
>
> Thanks, Arnd
>
> Makes sense.
>
> @Duoming Zhou,
>
> Can you provide a v2 with separate function using buffer on stack?
>
> static noinline_for_stack
> void brcmf_pcie_provide_random_bytes(struct brcmf_pciedev_info *devinfo,
> u32 address)
> {
> u8 randbuf[BRCMF_RANDOM_SEED_LENGTH];
> :
> :
> }
Thank you for your suggestions, I have already provided a v2.
Best regards,
Duoming Zhou
Powered by blists - more mailing lists