[PATCH wireless] wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe

[PATCH wireless] wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe

[Devin Wittmayer]

Some laptops carry a MediaTek power table in their firmware, and the
driver reads it to set a transmit limit for each frequency range. It
only fills in the ranges themselves when it registers the device.

The startup step that does this existed already, but it never programmed
anything. These two commits made it run a regulatory update instead,
which sets the limits on the way through, long before registration. So on
a machine that has the table the driver reads through an empty pointer
and the interface never appears:

  BUG: kernel NULL pointer dereference, address: 0000000000000004
  RIP: 0010:mt792x_init_acpi_sar_power
  Call Trace:
   mt7921_set_tx_sar_pwr
   mt7921_mcu_regd_update
   mt7921_regd_update
   mt7921_run_firmware
   mt7921e_mcu_init
   mt7921_init_work

Skip it when the ranges are missing. They are applied again once the
device is up, which is where they came from before.

Reported-by: Klara Modin <klarasmodin@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/aoyxqHYvSuaBeubf@soda.int.kasm.eu/
Fixes: 9b80bd9cab40 ("wifi: mt76: mt7921: add regulatory wiphy self manager support")
Fixes: e9f3f1cc133f ("wifi: mt76: mt7925: add regulatory wiphy self manager support")
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---

Reproduced on both chips before sending, an MT7922 and an MT7925, and the
fix clears both. Neither machine here ships a vendor power table, so I
supplied one through an ACPI override in the initrd. It also wants recent
firmware. The June builds do not turn on self-managed regulatory and
nothing happens; the builds now in linux-firmware do, and then it dies
exactly as reported with no interface at all. Patched, both come up and
scan normally, and the injected limits still show through in the power
table afterwards, so the skip does not lose them.

With that table still in place and the fix absent, backing out the mt7921
commit on its own also boots clean, so the table is not what causes this.

 drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
index 946dd7956e4a..b468051fbe68 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
@@ -323,7 +323,8 @@ int mt792x_init_acpi_sar_power(struct mt792x_phy *phy, bool set_default)
 	const struct cfg80211_sar_capa *capa = phy->mt76->hw->wiphy->sar_capa;
 	int i;
 
-	if (!phy->acpisar || !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
+	if (!capa || !phy->acpisar ||
+	    !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
 		return 0;
 
 	/* When ACPI SAR enabled in HW, we should apply rules for .frp
-- 
2.55.0

Re: [PATCH wireless] wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe

[Klara Modin]

On 2026-08-25 11:17:12 -0700, Devin Wittmayer wrote:
> Some laptops carry a MediaTek power table in their firmware, and the
> driver reads it to set a transmit limit for each frequency range. It
> only fills in the ranges themselves when it registers the device.
> 
> The startup step that does this existed already, but it never programmed
> anything. These two commits made it run a regulatory update instead,
> which sets the limits on the way through, long before registration. So on
> a machine that has the table the driver reads through an empty pointer
> and the interface never appears:
> 
>   BUG: kernel NULL pointer dereference, address: 0000000000000004
>   RIP: 0010:mt792x_init_acpi_sar_power
>   Call Trace:
>    mt7921_set_tx_sar_pwr
>    mt7921_mcu_regd_update
>    mt7921_regd_update
>    mt7921_run_firmware
>    mt7921e_mcu_init
>    mt7921_init_work
> 
> Skip it when the ranges are missing. They are applied again once the
> device is up, which is where they came from before.
> 
> Reported-by: Klara Modin <klarasmodin@gmail.com>
> Closes: https://lore.kernel.org/linux-wireless/aoyxqHYvSuaBeubf@soda.int.kasm.eu/
> Fixes: 9b80bd9cab40 ("wifi: mt76: mt7921: add regulatory wiphy self manager support")
> Fixes: e9f3f1cc133f ("wifi: mt76: mt7925: add regulatory wiphy self manager support")
> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> ---
> 
> Reproduced on both chips before sending, an MT7922 and an MT7925, and the
> fix clears both. Neither machine here ships a vendor power table, so I
> supplied one through an ACPI override in the initrd. It also wants recent
> firmware. The June builds do not turn on self-managed regulatory and
> nothing happens; the builds now in linux-firmware do, and then it dies
> exactly as reported with no interface at all. Patched, both come up and
> scan normally, and the injected limits still show through in the power
> table afterwards, so the skip does not lose them.
> 
> With that table still in place and the fix absent, backing out the mt7921
> commit on its own also boots clean, so the table is not what causes this.
> 

Thanks for the quick fix!

Regards,
Tested-by: Klara Modin <klarasmodin@gmail.com>

>  drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> index 946dd7956e4a..b468051fbe68 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> @@ -323,7 +323,8 @@ int mt792x_init_acpi_sar_power(struct mt792x_phy *phy, bool set_default)
>  	const struct cfg80211_sar_capa *capa = phy->mt76->hw->wiphy->sar_capa;
>  	int i;
>  
> -	if (!phy->acpisar || !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
> +	if (!capa || !phy->acpisar ||
> +	    !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
>  		return 0;
>  
>  	/* When ACPI SAR enabled in HW, we should apply rules for .frp
> -- 
> 2.55.0
> 

Re: [PATCH wireless] wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe

[Devin Wittmayer]

Thank you for the Tested-by, and for bisecting it in the first place. The
report arrived with the commit named and a revert confirmed, which is most of
the work already done.

Something odd, since we are on the same laptop. Mine is a Framework 13 that
shipped with an MT7922, and it has no MediaTek power tables at all. I checked
every ACPI table on the machine rather than only the main one, and there is
nothing there for any vendor. So your oops cannot fire here on the same model
with the same card, which is why I had to inject tables to reproduce it.

Which means the difference is somewhere in the firmware, and I can only see my
side of it. Mine is an Intel 11th generation board on BIOS 3.17, dated October
2022. What are you on? Whether these tables came with a later release or only
ever appeared on certain boards decides whether anyone else is about to walk
into this.

While you are in there, does your geo table carry 0xff in the unused slots?
Someone turned up on the list yesterday with an ASUS padded that way, which
the driver takes as roughly -1 dBm and clamps every rate down to it. Whether
that is one vendor's habit or common changes what the right fix looks like.

Devin

On 2026-08-25 11:27:15 +0000, Klara Modin wrote:
> On 2026-08-25 11:17:12 -0700, Devin Wittmayer wrote:
> > Some laptops carry a MediaTek power table in their firmware, and the
> > driver reads it to set a transmit limit for each frequency range. It
> > only fills in the ranges themselves when it registers the device.
> >
> > The startup step that does this existed already, but it never programmed
> > anything. These two commits made it run a regulatory update instead,
> > which sets the limits on the way through, long before registration. So on
> > a machine that has the table the driver reads through an empty pointer
> > and the interface never appears:
> >
> >   BUG: kernel NULL pointer dereference, address: 0000000000000004
> >   RIP: 0010:mt792x_init_acpi_sar_power
> >   Call Trace:
> >    mt7921_set_tx_sar_pwr
> >    mt7921_mcu_regd_update
> >    mt7921_regd_update
> >    mt7921_run_firmware
> >    mt7921e_mcu_init
> >    mt7921_init_work
> >
> > Skip it when the ranges are missing. They are applied again once the
> > device is up, which is where they came from before.
> >
> > Reported-by: Klara Modin <klarasmodin@gmail.com>
> > Closes: https://lore.kernel.org/linux-wireless/aoyxqHYvSuaBeubf@soda.int.kasm.eu/
> > Fixes: 9b80bd9cab40 ("wifi: mt76: mt7921: add regulatory wiphy self manager support")
> > Fixes: e9f3f1cc133f ("wifi: mt76: mt7925: add regulatory wiphy self manager support")
> > Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> > ---
> >
> > Reproduced on both chips before sending, an MT7922 and an MT7925, and the
> > fix clears both. Neither machine here ships a vendor power table, so I
> > supplied one through an ACPI override in the initrd. It also wants recent
> > firmware. The June builds do not turn on self-managed regulatory and
> > nothing happens; the builds now in linux-firmware do, and then it dies
> > exactly as reported with no interface at all. Patched, both come up and
> > scan normally, and the injected limits still show through in the power
> > table afterwards, so the skip does not lose them.
> >
> > With that table still in place and the fix absent, backing out the mt7921
> > commit on its own also boots clean, so the table is not what causes this.
> >
>
> Thanks for the quick fix!
>
> Regards,
> Tested-by: Klara Modin <klarasmodin@gmail.com>
>
> >  drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> > index 946dd7956e4a..b468051fbe68 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> > @@ -323,7 +323,8 @@ int mt792x_init_acpi_sar_power(struct mt792x_phy *phy, bool set_default)
> >  	const struct cfg80211_sar_capa *capa = phy->mt76->hw->wiphy->sar_capa;
> >  	int i;
> >
> > -	if (!phy->acpisar || !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
> > +	if (!capa || !phy->acpisar ||
> > +	    !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
> >  		return 0;
> >
> >  	/* When ACPI SAR enabled in HW, we should apply rules for .frp
> > --
> > 2.55.0
> >

Re: [PATCH wireless] wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe

[Klara Modin]

On 2026-08-27 18:17:37 -0700, Devin Wittmayer wrote:
> Thank you for the Tested-by, and for bisecting it in the first place. The
> report arrived with the commit named and a revert confirmed, which is most of
> the work already done.
> 
> Something odd, since we are on the same laptop. Mine is a Framework 13 that
> shipped with an MT7922, and it has no MediaTek power tables at all. I checked
> every ACPI table on the machine rather than only the main one, and there is
> nothing there for any vendor. So your oops cannot fire here on the same model
> with the same card, which is why I had to inject tables to reproduce it.

From my short look, the driver seems to look for MTCTL, MTDS, MTGS, and
MTFG? I don't have a MTFG, but the others look like this decoded with
iasl:

 Method (MTDS, 0, Serialized)
 {
     Name (_SPT, Package (0x1F)
     {
         0x4D, 0x54, 0x44, 0x53, One, Zero, 0x02,
         One, 0x22, 0x14, 0x24, 0x22, 0x21, 0x19, 0x1A,
         0x1A, 0x1A, 0x19, 0x1A, 0x02, 0x22, 0x14, 0x24,
         0x22, 0x21, 0x19, 0x1A, 0x1A, 0x1A, 0x19, 0x1A
     })
     Return (_SPT) /* \_SB_.PCI0.GPP6.WLAN.MTDS._SPT */
 }
 Method (MTGS, 0, Serialized)
 {
     Name (_GPT, Package (0x1C)
     {
         0x4D, 0x54, 0x47, 0x53, One, Zero, 0x03, One,
         0x24, 0x24, 0x24, 0x24, 0x1A, 0x1A, 0x02, 0x24,
         0x24, 0x24, 0x24, 0x1A, 0x1A, 0x03, 0x24, 0x24,
         0x24, 0x24, 0x1A, 0x1A
     })
     Return (_GPT) /* \_SB_.PCI0.GPP6.WLAN.MTGS._GPT */
 }
 Method (MTCL, 0, Serialized)
 {
     Name (_TCL, Package (0x13)
     {
         0x4D, 0x54, 0x43, 0x4C, 0x02, One, 0x50, 0x88,
         One, 0x18, Zero, Zero, One, Zero, Zero, Zero,
         0x08, Zero, Zero
     })
     Return (_TCL) /* \_SB_.PCI0.GPP6.WLAN.MTCL._TCL */
 }

> 
> Which means the difference is somewhere in the firmware, and I can only see my
> side of it. Mine is an Intel 11th generation board on BIOS 3.17, dated October
> 2022. What are you on? Whether these tables came with a later release or only
> ever appeared on certain boards decides whether anyone else is about to walk
> into this.

Wouldn't the Intel 11th generation have come with the Intel AX201 or
AX210 originally? Mine is the Ryzen 5 7640U and is updated to the 3.20
BIOS dated June 23 2026.

> 
> While you are in there, does your geo table carry 0xff in the unused slots?
> Someone turned up on the list yesterday with an ASUS padded that way, which
> the driver takes as roughly -1 dBm and clamps every rate down to it. Whether
> that is one vendor's habit or common changes what the right fix looks like.

I don't think so (if this is the MTGS table above?), but I don't really
know how to parse the table contents.

If I run `iw reg get` (with the patch applied) it returns:

 country SE: DFS-ETSI
 	(2400 - 2483 @ 40), (N/A, 20), (N/A)
 	(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
 	(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
 	(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
 	(5725 - 5875 @ 80), (N/A, 13), (N/A)
 	(5945 - 6425 @ 320), (N/A, 23), (N/A), NO-OUTDOOR
 	(57000 - 66000 @ 2160), (N/A, 40), (N/A)
 
 phy#0 (self-managed)
 country SE: DFS-ETSI
 	(2402 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, NO-320MHZ, NO-EHT
 	(5170 - 5250 @ 80), (6, 22), (N/A), AUTO-BW, NO-320MHZ, NO-EHT
 	(5250 - 5330 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-320MHZ, NO-EHT, PASSIVE-SCAN
 	(5490 - 5710 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-320MHZ, NO-EHT, PASSIVE-SCAN
 	(5735 - 5835 @ 80), (6, 22), (N/A), AUTO-BW, NO-320MHZ, NO-EHT
 	(5945 - 6425 @ 160), (6, 22), (N/A), AUTO-BW, NO-320MHZ, NO-EHT, PASSIVE-SCAN

so the transmit power limits actually look like they are too high for
some bands, especially 5735-5835, but maybe it will limit to the AP
transmit power and be fine? However, according to `iw list` the channels
in 5735-5835 do not have the "no IR" flag, so in AP mode the card could
potentially transmit ~8 times the allowed power (I would rather not test
this)?

The 5710-5735 range is also not covered, which results in 5 GHz channel
144 being disabled (visible in `iw list`).

> 
> Devin

Regards,
Klara Modin

> 
> On 2026-08-25 11:27:15 +0000, Klara Modin wrote:
> > On 2026-08-25 11:17:12 -0700, Devin Wittmayer wrote:
> > > Some laptops carry a MediaTek power table in their firmware, and the
> > > driver reads it to set a transmit limit for each frequency range. It
> > > only fills in the ranges themselves when it registers the device.
> > >
> > > The startup step that does this existed already, but it never programmed
> > > anything. These two commits made it run a regulatory update instead,
> > > which sets the limits on the way through, long before registration. So on
> > > a machine that has the table the driver reads through an empty pointer
> > > and the interface never appears:
> > >
> > >   BUG: kernel NULL pointer dereference, address: 0000000000000004
> > >   RIP: 0010:mt792x_init_acpi_sar_power
> > >   Call Trace:
> > >    mt7921_set_tx_sar_pwr
> > >    mt7921_mcu_regd_update
> > >    mt7921_regd_update
> > >    mt7921_run_firmware
> > >    mt7921e_mcu_init
> > >    mt7921_init_work
> > >
> > > Skip it when the ranges are missing. They are applied again once the
> > > device is up, which is where they came from before.
> > >
> > > Reported-by: Klara Modin <klarasmodin@gmail.com>
> > > Closes: https://lore.kernel.org/linux-wireless/aoyxqHYvSuaBeubf@soda.int.kasm.eu/
> > > Fixes: 9b80bd9cab40 ("wifi: mt76: mt7921: add regulatory wiphy self manager support")
> > > Fixes: e9f3f1cc133f ("wifi: mt76: mt7925: add regulatory wiphy self manager support")
> > > Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
> > > ---
> > >
> > > Reproduced on both chips before sending, an MT7922 and an MT7925, and the
> > > fix clears both. Neither machine here ships a vendor power table, so I
> > > supplied one through an ACPI override in the initrd. It also wants recent
> > > firmware. The June builds do not turn on self-managed regulatory and
> > > nothing happens; the builds now in linux-firmware do, and then it dies
> > > exactly as reported with no interface at all. Patched, both come up and
> > > scan normally, and the injected limits still show through in the power
> > > table afterwards, so the skip does not lose them.
> > >
> > > With that table still in place and the fix absent, backing out the mt7921
> > > commit on its own also boots clean, so the table is not what causes this.
> > >
> >
> > Thanks for the quick fix!
> >
> > Regards,
> > Tested-by: Klara Modin <klarasmodin@gmail.com>
> >
> > >  drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> > > index 946dd7956e4a..b468051fbe68 100644
> > > --- a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> > > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c
> > > @@ -323,7 +323,8 @@ int mt792x_init_acpi_sar_power(struct mt792x_phy *phy, bool set_default)
> > >  	const struct cfg80211_sar_capa *capa = phy->mt76->hw->wiphy->sar_capa;
> > >  	int i;
> > >
> > > -	if (!phy->acpisar || !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
> > > +	if (!capa || !phy->acpisar ||
> > > +	    !((struct mt792x_acpi_sar *)phy->acpisar)->dyn)
> > >  		return 0;
> > >
> > >  	/* When ACPI SAR enabled in HW, we should apply rules for .frp
> > > --
> > > 2.55.0
> > >

Re: [PATCH wireless] wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe

[Devin Wittmayer]

On 2026-08-28 15:27:10 +0000, Klara Modin wrote:
> Wouldn't the Intel 11th generation have come with the Intel AX201 or
> AX210 originally?

It would, and thanks for the correction. This board's firmware carries
Intel's wireless power methods and none of MediaTek's four. I put an
MT7927 in it recently and the MediaTek ones did not appear, so they do
not come with the card.

> I don't think so (if this is the MTGS table above?), but I don't really
> know how to parse the table contents.

That is the right table, and nothing in it is padded. Yours is fine.

> so the transmit power limits actually look like they are too high for
> some bands, especially 5735-5835, but maybe it will limit to the AP
> transmit power and be fine? However, according to `iw list` the channels
> in 5735-5835 do not have the "no IR" flag, so in AP mode the card could
> potentially transmit ~8 times the allowed power (I would rather not test
> this)?

Every line reads the same because the driver writes the same number into
all of them:

	/* not used by fw */
	rule->power_rule.max_antenna_gain = DBI_TO_MBI(6);
	rule->power_rule.max_eirp = DBM_TO_MBM(22);

It is a placeholder rather than anything the card sent up, which is why
the same twenty-two turns up under every country code and not only
yours. So it is not evidence of what the radio will do in that band, in
either direction. The card has a power table of its own, separate from
this one, and debugfs shows it as txpower_sku.

> The 5710-5735 range is also not covered, which results in 5 GHz channel
> 144 being disabled (visible in `iw list`).

That hole is in what the card replied with. The driver copies the ranges
across untouched, so 144 goes with it.

Devin