public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Hamer <marcel.hamer@windriver.com>
To: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: Kalle Valo <kvalo@kernel.org>,
	linux-wireless@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] brcmfmac: NULL pointer dereference on tx statistic update
Date: Tue, 14 Jan 2025 09:18:47 +0100	[thread overview]
Message-ID: <Z4Yd515dhZApbxPz@windriver.com> (raw)
In-Reply-To: <4020e574-be5d-43e4-9c04-1e5a708e70c6@broadcom.com>

Hello,

On Mon, Jan 13, 2025 at 08:28:33PM +0100, Arend van Spriel wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> On 1/10/2025 2:45 PM, Marcel Hamer wrote:
> > On removal of the device or unloading of the kernel module a potential
> > NULL pointer dereference occurs.
> > 
> > The following sequence deletes the interface:
> > 
> >    brcmf_detach()
> >      brcmf_remove_interface()
> >        brcmf_del_if()
> > 
> > Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to
> > BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.
> > 
> > After brcmf_remove_interface() call the brcmf_proto_detach() function is
> > called providing the following sequence:
> > 
> >    brcmf_detach()
> >      brcmf_proto_detach()
> >        brcmf_proto_msgbuf_detach()
> >          brcmf_flowring_detach()
> >            brcmf_msgbuf_delete_flowring()
> >              brcmf_msgbuf_remove_flowring()
> >                brcmf_flowring_delete()
> >                  brcmf_get_ifp()
> >                  brcmf_txfinalize()
> > 
> > Since brcmf_get_ip() can and actually will return NULL in this case the
> > call to brcmf_txfinalize() will result in a NULL pointer dereference
> > inside brcmf_txfinalize() when trying to update
> > ifp->ndev->stats.tx_errors.
> > 
> > This will only happen if a flowring still has an skb.
> > 
> > Although the NULL pointer dereference has only been seen when trying to update
> > the tx statistic, all other uses of the ifp pointer have been guarded as well.
> 
> Here my suggestion to make it a bit more simple...
> 
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Marcel Hamer <marcel.hamer@windriver.com>
> > Link: https://lore.kernel.org/all/b519e746-ddfd-421f-d897-7620d229e4b2@gmail.com/
> > ---
> > v1 -> v2: guard all uses of the ifp pointer inside brcmf_txfinalize()
> > ---
> >   drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> > index c3a57e30c855..791757a3ec13 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> > @@ -543,13 +543,13 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
> 
> Instead of checking ifp below you can simply do following here and be
> done with it:
> 
>        if (!ifp) {
>                brcmu_pkt_buf_free_skb(txp);
>                return;
>        }
>

Thank you for the suggestion and review. I considered that when doing my changes
and then thought it would be more efficient to only check the validity of ifp
when ifp is actually used. To skip checking it on each call to this function,
since it seems unlikely ifp will be used on each and every call.

Before I create a patch with your suggested changes, I just wanted to check if
you think it would be better to just wrap the two existing if statements in a
new if statement in that case, something like this:

if (ifp) {
    ...
    if (type == ETH_P_PAE) {
    ...
    }

    if (!success)
        ifp->ndev->stats.tx_errors++;
}

And then keep a single call to brcmu_pkt_buf_free_skb(txp) at the end of the
function.
 
> >       eh = (struct ethhdr *)(txp->data);
> >       type = ntohs(eh->h_proto);
> > 
> > -     if (type == ETH_P_PAE) {
> > +     if (type == ETH_P_PAE && ifp) {
> >               atomic_dec(&ifp->pend_8021x_cnt);
> >               if (waitqueue_active(&ifp->pend_8021x_wait))
> >                       wake_up(&ifp->pend_8021x_wait);
> >       }
> > 
> > -     if (!success)
> > +     if (!success && ifp)
> >               ifp->ndev->stats.tx_errors++;
> > 
> >       brcmu_pkt_buf_free_skb(txp);
> 

Kind regards,

Marcel

  reply	other threads:[~2025-01-14  8:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10 13:45 [PATCH v2] brcmfmac: NULL pointer dereference on tx statistic update Marcel Hamer
2025-01-13 19:28 ` Arend van Spriel
2025-01-14  8:18   ` Marcel Hamer [this message]
2025-01-15 15:57     ` Arend Van Spriel
2025-01-15 15:16 ` Kalle Valo
2025-01-15 16:02   ` Arend Van Spriel

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=Z4Yd515dhZApbxPz@windriver.com \
    --to=marcel.hamer@windriver.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=kvalo@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --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