From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Johannes Berg <johannes@sipsolutions.net>,
Abdun Nihaal <nihaal@cse.iitm.ac.in>
Cc: linux-wireless@vger.kernel.org, brcm80211@lists.linux.dev,
brcm80211-dev-list.pdl@broadcom.com,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()
Date: Mon, 3 Aug 2026 10:54:59 +0200 [thread overview]
Message-ID: <c5aad785-8d7d-4015-a3c9-1f70f2a69579@broadcom.com> (raw)
In-Reply-To: <e628d43a4aca1763cafcde41338cf7a34fe57d6c.camel@sipsolutions.net>
On 03/08/2026 10:35, Johannes Berg wrote:
> On Mon, 2026-08-03 at 10:21 +0200, Arend van Spriel wrote:
>>>
>>> I looked at moving the vfree() to the done: label, but the code also
>>> gets there in the success path to wakeup waiters. In the success path
>>> the buf is stored for further processing so it should not be freed.
>
> Hah, my bad, sorry!
>
>>> Maybe better to do:
>>>
>>> spin_unlock_bh(&bus->rxctl_lock);
>>> brcmf_sdio_dcmd_resp_wake(bus);
>>> return;
>>>
>>> fail:
>>> vfree(buf);
>>> /* Awake any waiters */
>>> brcmf_sdio_dcmd_resp_wake(bus);
>>> }
>> Actually it turns out brcmf_sdio_read_control() is only called once so
>> the brcmf_sdio_dcmd_resp_wake() can be taken outside the function.
>
> Or just something like this?
>
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -1827,15 +1827,17 @@ brcmf_sdio_read_control(struct brcmf_sdio *bus, u8 *hdr, uint len, uint doff)
> if (bus->rxctl) {
> brcmf_err("last control frame is being processed.\n");
> spin_unlock_bh(&bus->rxctl_lock);
> - vfree(buf);
> goto done;
> }
> bus->rxctl = buf + doff;
> bus->rxctl_orig = buf;
> bus->rxlen = len - doff;
> spin_unlock_bh(&bus->rxctl_lock);
> + /* buffer is queued */
> + buf = NULL;
>
> done:
> + vfree(buf);
> /* Awake any waiters */
> brcmf_sdio_dcmd_resp_wake(bus);
> }
>
>
> It's already using vmalloc() so seems it wouldn't care that much about
> calling vfree(NULL) on the success path?
True. And yes, the existing vfree() should go, but I figured that goes
without saying so I did not mention that. I am fine with your proposal,
but I guess the author will have to submit a v2 patch, right?
Gr. AvS
next prev parent reply other threads:[~2026-08-03 8:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 11:07 [PATCH] wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() Abdun Nihaal
2026-08-02 8:38 ` Arend van Spriel
2026-08-02 16:41 ` Johannes Berg
2026-08-02 16:44 ` Johannes Berg
2026-08-03 5:44 ` Arend van Spriel
2026-08-03 8:21 ` Arend van Spriel
2026-08-03 8:35 ` Johannes Berg
2026-08-03 8:54 ` Arend van Spriel [this message]
2026-08-03 8:57 ` Johannes Berg
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=c5aad785-8d7d-4015-a3c9-1f70f2a69579@broadcom.com \
--to=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211@lists.linux.dev \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nihaal@cse.iitm.ac.in \
--cc=stable@vger.kernel.org \
/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