In this function, bf is guarded by an if statement, indicating that it may
be NULL:

  if (bf && bf->bf_mpdu) {...}

If bf is NULL, calling list_add_tail() may result in a null-pointer
dereference:

  list_add_tail(&bf->list, &sc->beacon.bbuf);

Therefore, add a defensive NULL check before invoking list_add_tail() to
prevent this issue.

Signed-off-by: Tuo Li <islituo@gmail.com>
---
 drivers/net/wireless/ath/ath9k/beacon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
index 4a27e3753c03..e39e2738ba1a 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -236,7 +236,8 @@ void ath9k_beacon_remove_slot(struct ath_softc *sc, struct ieee80211_vif *vif)
 
 	avp->av_bcbuf = NULL;
 	sc->beacon.bslot[avp->av_bslot] = NULL;
-	list_add_tail(&bf->list, &sc->beacon.bbuf);
+	if (bf)
+		list_add_tail(&bf->list, &sc->beacon.bbuf);
 
 	tasklet_enable(&sc->bcon_tasklet);
 }
-- 
2.43.0

Tuo Li <islituo@gmail.com> writes:

> In this function, bf is guarded by an if statement, indicating that it may
> be NULL:
>
>   if (bf && bf->bf_mpdu) {...}
>
> If bf is NULL, calling list_add_tail() may result in a null-pointer
> dereference:
>
>   list_add_tail(&bf->list, &sc->beacon.bbuf);
>
> Therefore, add a defensive NULL check before invoking list_add_tail() to
> prevent this issue.
>
> Signed-off-by: Tuo Li <islituo@gmail.com>

Are you fixing an actual bug here? Otherwise, this is not worth the
churn...

-Toke

On Wed, Jan 7, 2026 at 6:03 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Tuo Li <islituo@gmail.com> writes:
>
> > In this function, bf is guarded by an if statement, indicating that it may
> > be NULL:
> >
> >   if (bf && bf->bf_mpdu) {...}
> >
> > If bf is NULL, calling list_add_tail() may result in a null-pointer
> > dereference:
> >
> >   list_add_tail(&bf->list, &sc->beacon.bbuf);
> >
> > Therefore, add a defensive NULL check before invoking list_add_tail() to
> > prevent this issue.
> >
> > Signed-off-by: Tuo Li <islituo@gmail.com>
>
> Are you fixing an actual bug here? Otherwise, this is not worth the
> churn...
>
> -Toke

Thanks for pointing this out.

This issue was reported by a static analysis tool. After reviewing the
code, I noticed that bf is guarded by an if statement, which indicates
that it may be NULL, so I added a defensive check before the other
dereference.

However, I have not been able to identify a concrete execution path in
which bf would actually be NULL at that point. I'm fine with dropping
this change if it is considered unnecessary.

Best regards,
Tuo