From: Johannes Berg <johannes@sipsolutions.net>
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
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, 03 Aug 2026 10:35:39 +0200 [thread overview]
Message-ID: <e628d43a4aca1763cafcde41338cf7a34fe57d6c.camel@sipsolutions.net> (raw)
In-Reply-To: <c2589f1c-c754-4282-815b-df64f0250623@broadcom.com> (sfid-20260803_102116_661427_959202E9)
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?
johannes
next prev parent reply other threads:[~2026-08-03 8:35 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 [this message]
2026-08-03 8:54 ` Arend van Spriel
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=e628d43a4aca1763cafcde41338cf7a34fe57d6c.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211@lists.linux.dev \
--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