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

[David Gow <david@davidgow.net>]

Le 26/08/2026 à 02:17, Devin Wittmayer a écrit :
> 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>
> ---

I can also confirm that this fixes the same NULL pointer dereference in 
7.3-rc1 here, also on a Framework 13 (Ryzen 7040):

BUG: kernel NULL pointer dereference, address: 0000000000000004
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 10 UID: 0 PID: 149 Comm: kworker/10:1 Tainted: G            E 
7.3.0-rc1-sulix+ #15 PREEMPT(full)  b7f05cce278af6607ac2dcae2fd785935bbe0dc6
Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, 
BIOS 03.05 03/29/2024
Workqueue: events mt7921_init_work [mt7921_common]
RIP: 0010:mt792x_init_acpi_sar_power+0x40/0x1ed [mt792x_lib]
(...)


Tested-by: David Gow <david@davidgow.net>

Thanks,
-- David


> 
> 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