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@xxxxxxxxxxxx>
Signed-off-by: Duoming Zhou <duoming@xxxxxxxxxx> --- 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:
smime.p7s
Description: S/MIME Cryptographic Signature
