patch 46/47 causes NULL pointer deref on mt7921

[Bert Karwatzki]

Am Freitag, dem 12.07.2024 um 13:06 +0200 schrieb Bert Karwatzki:
> Am Donnerstag, dem 11.07.2024 um 18:40 -0500 schrieb Sean Wang:
> > Hi Bert,
> >
> > Thanks for the detailed debug log. I've quickly made a change to fix
> > the issue. Right now, I can't access the test environment, but I'll
> > test it and send it out as soon as possible. Here's the patch.
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> > b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> > index 2e6268cb06c0..1bab93d049df 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> > @@ -303,6 +303,7 @@ mt7921_add_interface(struct ieee80211_hw *hw,
> > struct ieee80211_vif *vif)
> >
> >         mvif->bss_conf.mt76.omac_idx = mvif->bss_conf.mt76.idx;
> >         mvif->phy = phy;
> > +       mvif->bss_conf.vif = mvif;
> >         mvif->bss_conf.mt76.band_idx = 0;
> >         mvif->bss_conf.mt76.wmm_idx = mvif->bss_conf.mt76.idx %
> > MT76_CONNAC_MAX_WMM_SETS;
> >
>
> I wrote earlier that this patch works fine with linux-next-20240711 and at first
> it did, but then another NULL pointer error occured. I'm not sure if I can
> bisect this as it does not trigger automatically it seems. Also I'm currently
> bisecting the problem with linux-20240712
>
> Bert Karwatzki

Now the above mentioned NULL pointer dereference has happended again, this time
on linux-next-20240716. It cann be triggered by repeatedly turning the Wifi off
and on again. For further investigation I created this patch:

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
index 2e6268cb06c0..3ecedf7bc9f3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
@@ -303,6 +303,8 @@ mt7921_add_interface(struct ieee80211_hw *hw, struct
ieee80211_vif *vif)

 	mvif->bss_conf.mt76.omac_idx = mvif->bss_conf.mt76.idx;
 	mvif->phy = phy;
+	WARN(!phy, "%s: phy = NULL\n", __func__);
+	mvif->bss_conf.vif = mvif;
 	mvif->bss_conf.mt76.band_idx = 0;
 	mvif->bss_conf.mt76.wmm_idx = mvif->bss_conf.mt76.idx %
MT76_CONNAC_MAX_WMM_SETS;

@@ -1182,6 +1184,12 @@ static void mt7921_ipv6_addr_change(struct ieee80211_hw
*hw,
 				    struct inet6_dev *idev)
 {
 	struct mt792x_vif *mvif = (struct mt792x_vif *)vif->drv_priv;
+	printk(KERN_INFO "%s: mvif = %px\n", __func__, mvif);
+	printk(KERN_INFO "%s: mvif->phy = %px\n", __func__, mvif->phy);
+	if (!mvif->phy) {
+		printk(KERN_INFO "%s: mvif->phy = NULL\n", __func__);
+		return;
+	}
 	struct mt792x_dev *dev = mvif->phy->dev;
 	struct inet6_ifaddr *ifa;
 	struct in6_addr ns_addrs[IEEE80211_BSS_ARP_ADDR_LIST_LEN];

And the result is this (the WARN in mt7921_add_interface did not trigger):

[  367.121740] [    T861] wlp4s0: deauthenticating from 54:67:51:3d:a2:d2 by
local choice (Reason: 3=DEAUTH_LEAVING)
[  367.209603] [    T861] mt7921_ipv6_addr_change: mvif = ffff954e7500de40
[  367.209615] [    T861] mt7921_ipv6_addr_change: mvif->phy = 0000000000000000
[  367.209621] [    T861] mt7921_ipv6_addr_change: mvif->phy = NULL
[  367.250026] [    T861] mt7921_ipv6_addr_change: mvif = ffff954e7500de40
[  367.250034] [    T861] mt7921_ipv6_addr_change: mvif->phy = ffff954e44427768
[  367.251537] [    T861] mt7921_ipv6_addr_change: mvif = ffff954e7500de40
[  367.251542] [    T861] mt7921_ipv6_addr_change: mvif->phy = ffff954e44427768
[  369.977123] [    T862] wlp4s0: authenticate with 54:67:51:3d:a2:d2 (local
address=c8:94:02:c1:bd:69)
[  369.984864] [    T862] wlp4s0: send auth to 54:67:51:3d:a2:d2 (try 1/3)
[  370.006199] [    T104] wlp4s0: authenticated
[  370.006680] [    T104] wlp4s0: associate with 54:67:51:3d:a2:d2 (try 1/3)
[  370.059080] [     T98] wlp4s0: RX AssocResp from 54:67:51:3d:a2:d2
(capab=0x511 status=0 aid=2)
[  370.064067] [     T98] wlp4s0: associated

So mvif->phy can be NULL at the start of mt7921_ipv6_addr_change. The early
return in that case avoids the NULL pointer and mvif->phy has its usual value
again on the next call to mt7921_ipv6_addr_change so Wifi is working again. I
don't know how this could happen but perhaps you have an idea.

Bert Karwatzki