Bug 2515420

Created attachment 2154424 [details]
Kernel log from affected boot (Fedora 44, kernel 7.1.8-200.fc44.x86_64)

Two things going on.

1. The UBSAN: the 20260724 firmware ships a CLC record with idx 3.
   7.1.y's phy->clc[] has three entries (mt792x.h: POWER, POWER_EXT,
   BE_CTRL) and mt7921_load_clc() indexes it with the firmware's idx
   unchecked, so the record pointer is written past the array into the
   u64 chip_cap that follows it (mt792x.h:183-184 in v7.1.12). chip_cap
   holds the firmware capability bits the driver consults for
   CLC/11D/RF-pin handling (mt7921/main.c, mcu.c:1364, regd.c:375/392),
   so a corrupted value plausibly explains the txpower readout; I can't
   prove that part without the hardware.

2. Upstream: idx 3 is MT792x_CLC_REGD, added in v7.3-rc1 by 9b80bd9cab40
   with the driver-side regulatory support, and v7.3-rc1 also bounds-
   checks the idx (9417c5818a01, Fixes-tagged for stable). As written
   that check turns an unknown idx into -EINVAL from
   mt7921_run_firmware(): once backported to 7.1.y/7.2.y, MT7922 + this
   firmware = no Wi-Fi at all. Patch sent upstream to skip unknown record
   types instead, asking stable to take the two together:
   https://lore.kernel.org/all/20260901011840.416787-1-junjie.cao@intel.com/

For 7.1.y the pair (bounds check + skip) is the right backport; the
driver won't use the REGD record there, but it stops scribbling on
chip_cap. If you still have the 20260605 firmware, `iw dev wlp1s0 info`
and `dmesg | grep mt7921` from it would confirm whether the txpower
readout tracks the firmware.

Thanks Junjie,

I can confirm that I am still using the 20260724 firmware, and the UBSAN out-of-bounds error is present in mt7921_load_clc().

Fedora 44, kernel:

$ uname -r
7.1.12-200.fc44.x86_64

The interface still reports 3.00 dBm:

$ iw dev wlp1s0 info
Interface wlp1s0
        type managed
        channel 40 (5200 MHz), width: 80 MHz, center1: 5210 MHz
        txpower 3.00 dBm

And dmesg shows:

mt7921e 0000:01:00.0: ASIC revision: 79220010
mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260724143257a
mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20260724143402
UBSAN: array-index-out-of-bounds in drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:474:15
mt7921_load_clc+0x2db/0x350 [mt7921_common]
mt7921_run_firmware+0x91/0xf0 [mt7921_common]

So this machine seems to reproduce exactly the 20260724 firmware / CLC out-of-bounds issue you described.

The reported txpower remains consistently at 3.00 dBm.

Let me know if you would like me to test a patched kernel or provide any additional logs.

That log settles the UBSAN part, and it makes me retract half of
comment 2.

txpower 3.00 dBm: unrelated to the firmware or to the CLC overrun. In
7.1.y nothing in the mt7921 path writes phy->txpower_cur (the writers in
mt76 are mt7603/mt7615/mt76x0/mt76x2/mt7915/mt7996 only), and mt7921's
get_txpower is the generic mt76_get_txpower(), which reports
(txpower_cur + path delta) / 2; with two chains the delta is 6, so
(0 + 6) / 2 = 3 dBm. It is a constant readout, not a limit the firmware
applies, which matches your throughput observation. 7.2 replaced the
callback with mt792x_get_txpower() (879d754e48f6, "wifi: mt76: mt792x:
report txpower for the requested vif link"), which derives the value
from the channel's power limits. That commit has no Fixes: tag and is
not in 7.1.12; a 7.2.x kernel (Rawhide, or a koji build if one exists
for F44) should show a value that tracks the channel instead of a
constant 3.

UBSAN on 7.1.12: mcu.c:474 is the read in `if (phy->clc[clc->idx])`.
phy->clc[3] aliases phy->chip_cap, which mt7921_mcu_get_nic_capability()
fills from the firmware's GET_NIC_CAPAB before mt7921_load_clc() runs.
Mikhail Gavrilov observed it non-zero on the same chip and firmware, so
the loop takes the `continue` and nothing is written. The warning is
real, but on this hardware nothing is corrupted, and my comment 2 guess
that chip_cap feeds the txpower readout was wrong.

Upstream status:

- v7.3-rc1 carries 9417c5818a01 ("validate CLC firmware records"),
  which turns the idx 3 record into -EINVAL: with this firmware mt7921e
  retries the firmware ten times and gives up ("hardware init failed",
  no interface) -- reported by Mikhail on MT7922.
- The follow-up that skips unknown records is pending in linux-wireless
  (Laxman Acharya Padhya; Tested-by Mikhail Gavrilov on MT7922 +
  linux-firmware 20260810):
  https://lore.kernel.org/linux-wireless/20260816174841.1918-1-acharyalaxman8848@gmail.com/
  My patch from comment 2 duplicates it and is withdrawn.
- v7.3-rc1 has a second MT7922 regression from the same regulatory
  series: NULL dereference in mt792x_init_acpi_sar_power() during probe
  on machines whose ACPI exports MediaTek SAR methods (MTDS/MTGS/MTCL),
  reported on a Framework 13. Fix pending, Tested-by from the reporter:
  https://lore.kernel.org/linux-wireless/20260825181712.28548-1-lucid_duck@justthetip.ca/
  Whether this Zenbook is exposed:
    sudo grep -a -c -E 'MTCL|MTDS|MTGS' /sys/firmware/acpi/tables/DSDT
  A non-zero count means a Rawhide 7.3-rc1 test would hit that path
  before the CLC one.

For Fedora (Justin): 9417c5818a01 has Fixes: 23bdc5d8cadf and is a
candidate for 7.1.y/7.2.y via the stable Fixes-tag scan. On its own it
makes MT7922 + mt7xxx-firmware-20260810 fail to probe. If it shows up in
a stable queue, it needs the skip patch above alongside; I have raised
the same with stable on the list.

Nothing to test on 7.1.12 for the CLC part; the fix only matters once
the validation commit reaches stable.

Thanks Junjie.

I checked the DSDT on this Zenbook, and the result is non-zero:

$ sudo grep -a -c -E 'MTCL|MTDS|MTGS' /sys/firmware/acpi/tables/DSDT
3

So this machine does expose the MediaTek SAR ACPI methods.

Thanks also for clarifying the 3.00 dBm readout. I'll be happy to test a Fedora 44 7.2.x kernel or a patched build if useful.

Count 3 means this Zenbook should hit the Framework 13 oops on
7.3-rc1: mt792x_init_acpi_sar_power() dereferences a NULL sar_capa
during probe and no interface appears. Skip Rawhide until the ACPI
SAR fix is merged; it is not, as of today.

Correction to comment 4: 7.3-rc1 is not broken by 9417c5818a01 on
its own. e9f3f1cc133f, also in 7.3-rc1, grew phy->clc[] to four
entries, so the idx 3 record fits and regd.c consumes it. The probe
failure Mikhail reported was 9417c5818a01 applied on a v7.2 tree
with the three-entry array, which is the shape of 7.1.y and 7.2.y.
So the -EINVAL risk is stable-only: any backport of 9417c5818a01
needs the skip patch alongside. Neither is queued for 7.1 or 7.2 as
of 2026-08-31.

F44 has no 7.2.x build (updates and updates-testing carry 7.1.12-200
only). 7.2 would only change the iw readout, so nothing to test there.

One check on 7.1.12 is useful. Two recent reports on ASUS MT7922
laptops (Vivobook S14 M5406WA, a ROG model) found the firmware's ACPI
MTGS geo table misparsed, which clamps the real per-rate power; the
Vivobook showed 3 in txpower_sku before the fix and 25 after. Same
number as your iw readout, different mechanism:

  sudo sh -c 'cat /sys/kernel/debug/ieee80211/phy*/mt76/txpower_sku'

Please paste the whole table. Values in the twenties for the 5 GHz
rates mean the tables are fine here; values around 3 mean this board
has the ASUS table problem as well:
  https://lore.kernel.org/linux-wireless/20260827134820.2607530-1-huynguyendinhquang@gmail.com/
  https://lore.kernel.org/linux-wireless/20260811232839.515463-1-lucid_duck@justthetip.ca/

Either way the decoded methods settle which table layout this
ships (package acpica-tools):

  sudo acpidump -b -n DSDT && iasl -d dsdt.dat && grep -A 14 -dt.dsl

Please paste the three Method blocks.

(In reply to junjie.cao from comment #6)
> Count 3 means this Zenbook should hit the Framework 13 oops on
> 7.3-rc1: mt792x_init_acpi_sar_power() dereferences a NULL sar_capa
> during probe and no interface appears. Skip Rawhide until the ACPI
> SAR fix is merged; it is not, as of today.
> 
> Correction to comment 4: 7.3-rc1 is not broken by 9417c5818a01 on
> its own. e9f3f1cc133f, also in 7.3-rc1, grew phy->clc[] to four
> entries, so the idx 3 record fits and regd.c consumes it. The probe
> failure Mikhail reported was 9417c5818a01 applied on a v7.2 tree
> with the three-entry array, which is the shape of 7.1.y and 7.2.y.
> So the -EINVAL risk is stable-only: any backport of 9417c5818a01
> needs the skip patch alongside. Neither is queued for 7.1 or 7.2 as
> of 2026-08-31.
> 
> F44 has no 7.2.x build (updates and updates-testing carry 7.1.12-200
> only). 7.2 would only change the iw readout, so nothing to test there.
> 
> One check on 7.1.12 is useful. Two recent reports on ASUS MT7922
> laptops (Vivobook S14 M5406WA, a ROG model) found the firmware's ACPI
> MTGS geo table misparsed, which clamps the real per-rate power; the
> Vivobook showed 3 in txpower_sku before the fix and 25 after. Same
> number as your iw readout, different mechanism:
> 
>   sudo sh -c 'cat /sys/kernel/debug/ieee80211/phy*/mt76/txpower_sku'
> 
> Please paste the whole table. Values in the twenties for the 5 GHz
> rates mean the tables are fine here; values around 3 mean this board
> has the ASUS table problem as well:
>  
> https://lore.kernel.org/linux-wireless/20260827134820.2607530-1-
> huynguyendinhquang/
>  
> https://lore.kernel.org/linux-wireless/20260811232839.515463-1-
> lucid_duck/
> 
> Either way the decoded methods settle which table layout this
> ships (package acpica-tools):
> 
>   sudo acpidump -b -n DSDT && iasl -d dsdt.dat && grep -A 14 -dt.dsl
> 
> Please paste the three Method blocks.

The acpidump line in comment 6 lost characters in
the paste. Three commands instead:

  sudo acpidump -b -n DSDT
  iasl -d dsdt.dat
  grep -A 14 -E 'Method \(MT(DS|GS|CL)' dsdt.dsl

Thanks Junjie.

I checked txpower_sku. On Fedora 44 / kernel 7.1.12 the debugfs filename uses an underscore (txpower_sku) rather than a hyphen.

$ sudo cat /sys/kernel/debug/ieee80211/phy0/mt76/txpower_sku
Tx power table (channel 42)

OFDM (eeprom) : 39 39 39 39 36 36 36 34
OFDM (tmac)   :  3  3  3  3  3  3  3  3

HT20 (eeprom): 37 37 37 35 35 34 34 32
HT20 (tmac)  :  3  3  3  3  3  3  3  3

VHT80 (eeprom): 37 37 37 35 35 34 34 32 30 30 0 0
VHT80 (tmac)  :  3  3  3  3  3  3  3  3  3  3 0 0

HE996 (eeprom): 37 37 37 35 35 34 34 32 30 30 25 25
HE996 (tmac)  :  3  3  3  3  3  3  3  3  3  3  3  3

So the TMAC values are indeed 3 across the table, which seems to match the ASUS MT7922 cases you mentioned.

I also dumped the DSDT. All three methods are present:

Method (MTDS, 0, Serialized)
Method (MTGS, 0, Serialized)
Method (MTCL, 0, Serialized)

MTCL returns this package:

0x4D, 0x54, 0x43, 0x4C, 0x02, One,
0xF9, 0xCF, 0xC7, 0xD8,
Zero, Zero, One, Zero, Zero, Zero,
0x08, Zero, Zero

I can provide the full txpower_sku output and the complete MTDS/MTGS methods if useful.

tmac 3 on every rate is a real clamp: the firmware is
transmitting at about 1.5 dBm while the EEPROM allows
34-39 (17-19.5 dBm; the table is in 0.5 dB units). So
this laptop has the ASUS SAR table problem on top of
the readout quirk. On the Vivobook the same clamp cut
5 GHz TX throughput to ~40 Mbps (200-350 after the
fix); an iperf3 upload test would show whether it
bites here too.

Your MTCL is a valid 19-byte v2 table, so MTDS and MTGS
are parsed with the v2 layouts (12-byte and 7-byte
entries). Which of the two known causes applies needs
those two tables: please paste the complete MTDS and
MTGS packages, all bytes in order. If MTGS carries
0xff power bytes it is the Vivobook case; if the
lengths do not fit the v2 layouts it is the ROG case,
where the fix rejects the tables. Both patches are
linked in comment 6.

Thanks Junjie.

Here are the complete MTDS and MTGS methods from the DSDT, exactly as output by iasl/awk.

MTDS:

        Method (MTDS, 0, Serialized)
        {
            If ((MD6G == One))
            {
                Name (MDSP, Package (0x1F)
                {
                    0x4D, 
                    0x54, 
                    0x44, 
                    0x53, 
                    Zero, 
                    Zero, 
                    Zero, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF
                })
                If ((MDSE >= One))
                {
                    MDSP [0x04] = MDSE /* \_SB_.MDSE */
                    MDSP [0x06] = MDSN /* \_SB_.MDSN */
                    MDSP [0x07] = MD1T /* \_SB_.MD1T */
                    MDSP [0x08] = MD10 /* \_SB_.MD10 */
                    MDSP [0x09] = MD11 /* \_SB_.MD11 */
                    MDSP [0x0A] = MD12 /* \_SB_.MD12 */
                    MDSP [0x0B] = MD13 /* \_SB_.MD13 */
                    MDSP [0x0C] = MD14 /* \_SB_.MD14 */
                    MDSP [0x0D] = MD15 /* \_SB_.MD15 */
                    MDSP [0x0E] = MD16 /* \_SB_.MD16 */
                    MDSP [0x0F] = MD17 /* \_SB_.MD17 */
                    MDSP [0x10] = MD18 /* \_SB_.MD18 */
                    MDSP [0x11] = MD19 /* \_SB_.MD19 */
                    MDSP [0x12] = MD1A /* \_SB_.MD1A */
                    MDSP [0x13] = MD2T /* \_SB_.MD2T */
                    MDSP [0x14] = MD20 /* \_SB_.MD20 */
                    MDSP [0x15] = MD21 /* \_SB_.MD21 */
                    MDSP [0x16] = MD22 /* \_SB_.MD22 */
                    MDSP [0x17] = MD23 /* \_SB_.MD23 */
                    MDSP [0x18] = MD24 /* \_SB_.MD24 */
                    MDSP [0x19] = MD25 /* \_SB_.MD25 */
                    MDSP [0x1A] = MD26 /* \_SB_.MD26 */
                    MDSP [0x1B] = MD27 /* \_SB_.MD27 */
                    MDSP [0x1C] = MD28 /* \_SB_.MD28 */
                    MDSP [0x1D] = MD29 /* \_SB_.MD29 */
                    MDSP [0x1E] = MD2A /* \_SB_.MD2A */
                }

                Return (MDSP) /* \_SB_.PCI0.GPP6.WLAN.MTDS.MDSP */
            }
            Else
            {
                Name (MDSB, Package (0x12)
                {
                    0x4D, 
                    0x54, 
                    0x44, 
                    0x53, 
                    Zero, 
                    Zero, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF
                })
                If ((MDSE == One))
                {
                    MDSB [0x04] = One
                    MDSB [0x05] = MDSN /* \_SB_.MDSN */
                    MDSB [0x06] = MD1T /* \_SB_.MD1T */
                    MDSB [0x07] = MD10 /* \_SB_.MD10 */
                    MDSB [0x08] = MD11 /* \_SB_.MD11 */
                    MDSB [0x09] = MD12 /* \_SB_.MD12 */
                    MDSB [0x0A] = MD13 /* \_SB_.MD13 */
                    MDSB [0x0B] = MD14 /* \_SB_.MD14 */
                    MDSB [0x0C] = MD2T /* \_SB_.MD2T */
                    MDSB [0x0D] = MD20 /* \_SB_.MD20 */
                    MDSB [0x0E] = MD21 /* \_SB_.MD21 */
                    MDSB [0x0F] = MD22 /* \_SB_.MD22 */
                    MDSB [0x10] = MD23 /* \_SB_.MD23 */
                    MDSB [0x11] = MD24 /* \_SB_.MD24 */
                }

                Return (MDSB) /* \_SB_.PCI0.GPP6.WLAN.MTDS.MDSB */
            }
        }



MTGS:

        Method (MTGS, 0, Serialized)
        {
            If ((MD6G == One))
            {
                Name (MGSP, Package (0x31)
                {
                    0x4D, 
                    0x54, 
                    0x47, 
                    0x53, 
                    One, 
                    Zero, 
                    Zero, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF
                })
                If ((MDSE >= One))
                {
                    MGSP [0x04] = MGSV /* \_SB_.MGSV */
                    MGSP [0x06] = MGSN /* \_SB_.MGSN */
                    MGSP [0x07] = MGS1 /* \_SB_.MGS1 */
                    MGSP [0x08] = MG10 /* \_SB_.MG10 */
                    MGSP [0x09] = MG11 /* \_SB_.MG11 */
                    MGSP [0x0A] = MG12 /* \_SB_.MG12 */
                    MGSP [0x0B] = MG13 /* \_SB_.MG13 */
                    MGSP [0x0C] = MG14 /* \_SB_.MG14 */
                    MGSP [0x0D] = MG15 /* \_SB_.MG15 */
                    MGSP [0x0E] = MGS2 /* \_SB_.MGS2 */
                    MGSP [0x0F] = MG20 /* \_SB_.MG20 */
                    MGSP [0x10] = MG21 /* \_SB_.MG21 */
                    MGSP [0x11] = MG22 /* \_SB_.MG22 */
                    MGSP [0x12] = MG23 /* \_SB_.MG23 */
                    MGSP [0x13] = MG24 /* \_SB_.MG24 */
                    MGSP [0x14] = MG25 /* \_SB_.MG25 */
                    MGSP [0x15] = MGS3 /* \_SB_.MGS3 */
                    MGSP [0x16] = MG30 /* \_SB_.MG30 */
                    MGSP [0x17] = MG31 /* \_SB_.MG31 */
                    MGSP [0x18] = MG32 /* \_SB_.MG32 */
                    MGSP [0x19] = MG33 /* \_SB_.MG33 */
                    MGSP [0x1A] = MG34 /* \_SB_.MG34 */
                    MGSP [0x1B] = MG35 /* \_SB_.MG35 */
                    MGSP [0x1C] = MGS4 /* \_SB_.MGS4 */
                    MGSP [0x1D] = MG40 /* \_SB_.MG40 */
                    MGSP [0x1E] = MG41 /* \_SB_.MG41 */
                    MGSP [0x1F] = MG42 /* \_SB_.MG42 */
                    MGSP [0x20] = MG43 /* \_SB_.MG43 */
                    MGSP [0x21] = MG44 /* \_SB_.MG44 */
                    MGSP [0x22] = MG45 /* \_SB_.MG45 */
                    MGSP [0x23] = MGS5 /* \_SB_.MGS5 */
                    MGSP [0x24] = MG50 /* \_SB_.MG50 */
                    MGSP [0x25] = MG51 /* \_SB_.MG51 */
                    MGSP [0x26] = MG52 /* \_SB_.MG52 */
                    MGSP [0x27] = MG53 /* \_SB_.MG53 */
                    MGSP [0x28] = MG54 /* \_SB_.MG54 */
                    MGSP [0x29] = MG55 /* \_SB_.MG55 */
                    MGSP [0x2A] = MGS6 /* \_SB_.MGS6 */
                    MGSP [0x2B] = MG60 /* \_SB_.MG60 */
                    MGSP [0x2C] = MG61 /* \_SB_.MG61 */
                    MGSP [0x2D] = MG62 /* \_SB_.MG62 */
                    MGSP [0x2E] = MG63 /* \_SB_.MG63 */
                    MGSP [0x2F] = MG64 /* \_SB_.MG64 */
                    MGSP [0x30] = MG65 /* \_SB_.MG65 */
                }

                Return (MGSP) /* \_SB_.PCI0.GPP6.WLAN.MTGS.MGSP */
            }
            Else
            {
                Name (MGSB, Package (0x15)
                {
                    0x4D, 
                    0x54, 
                    0x47, 
                    0x53, 
                    One, 
                    Zero, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    Zero, 
                    0xFF, 
                    0xFF, 
                    0xFF, 
                    0xFF
                })
                If ((MDSE == One))
                {
                    MGSB [0x05] = MGSN /* \_SB_.MGSN */
                    MGSB [0x06] = MGS1 /* \_SB_.MGS1 */
                    MGSB [0x07] = MG10 /* \_SB_.MG10 */
                    MGSB [0x08] = MG11 /* \_SB_.MG11 */
                    MGSB [0x09] = MG12 /* \_SB_.MG12 */
                    MGSB [0x0A] = MG13 /* \_SB_.MG13 */
                    MGSB [0x0B] = MGS2 /* \_SB_.MGS2 */
                    MGSB [0x0C] = MG20 /* \_SB_.MG20 */
                    MGSB [0x0D] = MG21 /* \_SB_.MG21 */
                    MGSB [0x0E] = MG22 /* \_SB_.MG22 */
                    MGSB [0x0F] = MG23 /* \_SB_.MG23 */
                    MGSB [0x10] = MGS3 /* \_SB_.MGS3 */
                    MGSB [0x11] = MG30 /* \_SB_.MG30 */
                    MGSB [0x12] = MG31 /* \_SB_.MG31 */
                    MGSB [0x13] = MG32 /* \_SB_.MG32 */
                    MGSB [0x14] = MG33 /* \_SB_.MG33 */
                }

                Return (MGSB) /* \_SB_.PCI0.GPP6.WLAN.MTGS.MGSB */
            }
        }


Let me know if you also need the values of the MDxx/MGxx objects referenced by these methods, or any other ACPI data from this machine.

Thanks. Those two methods are templates, so they show
the mechanism but not the numbers: the packages hold
0xff placeholders and the real values are copied in
from \_SB.MDxx / \_SB.MGxx when MDSE >= 1. The sizes
(31 and 49 bytes) fit the v2 layouts, 2 dynamic and 6
geo tables, so unless MDSN/MGSN disagree with those
counts this is not the ROG length case.

If the clamp comes from this path, MDSE is >= 1 here
and for channel 42 in France the driver applied MD11
(dynamic limit for 5150-5350 MHz, first table only)
and MG22/MG23 (geo entry 2 = ETSI, 5 GHz
power/offset); a 0xff in MD11 or MG22 reads as -1 dBm
and wins the min(). If those values turn out sane,
ACPI SAR is not the cause and the next suspect is the
firmware's own country power table, which would not
be ASUS-specific.

So yes, please paste the definitions of the referenced
objects. They may sit in an SSDT rather than the DSDT,
so dump every table:

  mkdir acpi && cd acpi
  sudo acpidump -b
  iasl -d *.dat
  grep -nE 'M[DG][0-9A-Z]{2}\b' *.dsl | grep -v 'M[DG]S[PB]'

If they are Name objects the values are right there.
If they are fields of an OperationRegion, say so and
we will find another way to read them at runtime.

Optional cross-check while connected on channel 42:

  sudo iw reg set 00
  sleep 3
  sudo iw reg get | head -2
  sudo cat /sys/kernel/debug/ieee80211/phy0/mt76/txpower_sku
  sudo iw reg set FR

Changing the regulatory domain re-applies the SAR
tables with the world geo entry instead of the ETSI
one. tmac rising above 3 there points at the ETSI
entry (or the country table); tmac still 3 points at
MD11 or away from ACPI SAR.

Thanks. I dumped all ACPI tables as suggested.

The referenced MDxx/MGxx objects are 8-bit fields rather than Name objects. For example, the DSDT contains:

MD6G,   8,
MDSE,   8,
MDSN,   8,
MD1T,   8,
MD10,   8,
MD11,   8,
MD12,   8,
MD13,   8,
MD14,   8,
MD15,   8,
MD16,   8,
MD17,   8,
MD18,   8,
MD19,   8,
MD1A,   8,
MD2T,   8,
MD20,   8,
MD21,   8,
MD22,   8,
MD23,   8,
MD24,   8,
MD25,   8,
MD26,   8,
MD27,   8,
MD28,   8,
MD29,   8,
MD2A,   8,
MGSV,   8,
MGSN,   8,
MGS1,   8,
MG10,   8,
MG11,   8,
MG12,   8,
...

I also ran the optional regulatory-domain cross-check while still connected on channel 42.

Exact commands/output:

fabien@fedora:~/acpi$ sudo iw reg set 00
sleep 3
sudo iw reg get | head -2
sudo cat /sys/kernel/debug/ieee80211/phy0/mt76/txpower_sku
sudo iw reg set FR
global
country 00: DFS-UNSET
Tx power table (channel 42)
                     1m     2m     5m    11m
CCK (user)      :    N.A    N.A    N.A    N.A
CCK (eeprom)    :     32     32     32     32
CCK (tmac)      :     48     48     48     48
                     6m     9m    12m    18m    24m    36m    48m    54m
OFDM (user)     :     -1     -1     -1     -1     -1     -1     -1     -1
OFDM (eeprom)   :     39     39     39     39     36     36     36     34
OFDM (tmac)     :      3      3      3      3      3      3      3      3

HT/VHT/HE tmac values also all remain at 3 (apart from the unsupported zero entries), just as before.

So changing the regulatory domain to 00 changed the CCK tmac value from 36 to 48, but the OFDM/HT/VHT/HE values remain clamped at 3.

This seems to match the case you described where the clamp remains at MD11 or away from the ACPI SAR country table.

Since the MDxx/MGxx objects are fields of an OperationRegion, please let me know what runtime-reading method or additional ACPI context you would like me to test next.

Still reproducible with Fedora 44 kernel 7.1.13-200.fc44.x86_64.

iw dev wlp1s0 info still reports:

txpower 3.00 dBm

The same UBSAN warning is still present at boot:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:474:15

index 3 is out of range for type 'void *[3]'

Firmware build is unchanged:

20260724143402

Still reproducing on 7.1.13 is expected: nothing for this
bug has reached any tree since comment 6. As of 2026-09-06
the 7.1 and 7.2 stable queues carry neither CLC patch nor
any mt792x SAR change, and the ACPI SAR probe fix for
7.3-rc1 is still unmerged, so Rawhide stays a no-go here.
F44 has a 7.2.3-300 build in koji (2026-09-03, not yet in
updates-testing). It carries the same SAR code; the only
visible change is the iw readout, which prints the
driver's own limit for the channel: expect 0-2 dBm there,
not 3, and not a fix.

The reg 00 result narrows it. On a 5 GHz channel the
driver sends the firmware a per-rate limit table that
covers OFDM/HT/VHT/HE and leaves CCK at the maximum, so
CCK follows the firmware's country table (36 -> 48) while
the other rows show the driver's number, min(regulatory,
SAR). That number stayed 3 across both geo entries (ETSI =
MG22/MG23, world = MG32/MG33), so the clamp is either MD11
(dynamic limit, 5150-5350 MHz, first table) or 0xff in
both MG22 and MG32. A 0xff byte reads as -1, and -1 in
that table is what showed as tmac 3 on the Vivobook.

Reading the fields at runtime: /dev/mem is closed on
Fedora (lockdown under Secure Boot; IO_STRICT_DEVMEM
covers NVS regardless), but Fedora kernels are built with
CONFIG_ACPI_DEBUG, so the ACPI interpreter can log every
field read while the two methods run. The driver
evaluates them at probe, so a module reload triggers
them. As root:

cd /sys/module/acpi/parameters
echo 0xffffffff > trace_debug_layer
echo 0x1c10 > trace_debug_level
for m in MTDS MTGS; do
  printf %s _SB.PCI0.GPP6.WLAN.$m > trace_method_name
  echo method > trace_state
  modprobe -r mt7921e && modprobe mt7921e
  sleep 5
done
echo disable > trace_state
dmesg | grep -E 'Method|RegionField|Value Read' > sar.txt

Please attach sar.txt. Each field appears as a
"Name [MD11] (RegionField) ... found in scope" line
followed by "Value Read 00000000000000xx, Width 1"; the
"Method Begin/End" lines separate the two runs. Wi-Fi
drops for a few seconds per reload; NetworkManager
reconnects on its own. printf rather than echo is
deliberate: the name must not carry a newline.

In case the trace comes back empty, also paste the
OperationRegion and Field lines that head the block
containing MD6G (grep -n 'MD6G,' *.dsl, then look a few
lines up).

MD11 or MG22/MG32 at 0xff means an ASUS table filled with
placeholders; the driver needs to treat 0xff as "no
limit" in the dynamic path too, which neither pending
patch does yet, and this machine would be the test case.
Sane values there put the cause outside ACPI SAR.

Created attachment 2156971 [details]
ACPI SAR trace (MTDS/MTGS)

anks Junjie. The ACPI trace worked; I have attached sar.txt.

The trace shows that both values you mentioned are indeed 0xff:

Name [MG22] (RegionField) ... found in scope [_SB_]
Value Read 00000000000000FF, Width 1

Name [MG32] (RegionField) ... found in scope [_SB_]
Value Read 00000000000000FF, Width 1

Several other MGxx power fields are also 0xff.

So this appears to match the ASUS placeholder-table case you described.

The resulting filtered trace contains the MTGS run, but I do not appear to see the MTDS/MD11 portion in sar.txt. Let me know if you would like me to rerun MTDS separately or perform any additional test.

Still reproducible with Fedora 44 kernel 7.2.4-200.fc44.x86_64.

The UBSAN warning is still present at boot:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:471:15

index 3 is out of range for type 'void *[3]'

Workqueue: events mt7921_init_work [mt7921_common]

The txpower reporting has changed compared to kernel 7.1.13:

7.1.13: txpower 3.00 dBm

7.2.4: txpower 0.00 dBm

Firmware build is unchanged:

20260724143402

Heads-up for Fedora first. 9417c5818a01 ("validate CLC
firmware records") is in today's 7.2.6-rc1 review on its
own, without the skip patch. On the three-entry array of
7.2.y that turns this firmware's idx 3 record into
-EINVAL and mt7921e never probes, so a kernel-7.2.6 built
from it leaves this laptop without Wi-Fi. I have asked
stable to drop it until the skip patch lands upstream:
https://lore.kernel.org/all/20260912144314.573358-1-junjie.cao@intel.com/
If it ships anyway, the F44 build needs the skip patch
alongside; I will open a kernel-ark MR then.

Comment 16 is what 7.2 should show: mt792x_get_txpower()
prints the driver's limit, and the SAR clamp of -1 in
0.5 dB units rounds to 0.00. UBSAN moved from line 474
to 471 with the 7.2 source, same read. Nothing to test on
7.2.4 or 7.2.5, and Rawhide is still out: 7.3-rc2 shipped
without the ACPI SAR probe fix.

The trace settles the geo side. sar.txt holds the last
43 of MTGS's 46 reads; the trace volume pushed everything
before them, the MTDS run included, out of the ring
buffer, hence no MD11. MTGS has 6 tables and every power
byte in all six is 0xff:

  tbl idx  2G pwr/off  5G pwr/off  6G pwr/off
   0   1     ff/00       ff/00       ff/00   (FCC)
   1   2     ff/ff       ff/ff       ff/ff   (ETSI)
   2   3     ff/00       ff/00       ff/00   (world)
   3-5 4-6   ff/ff       ff/ff       ff/ff

Each reads as -1, so the geo limit wins the min() against
whatever MD11 holds. That is the Vivobook case, and it
predicts 2.4 GHz is clamped the same way.

Patch on linux-wireless, treating 0xff as no limit in
both tables, with your MTGS bytes as the test case:
https://lore.kernel.org/linux-wireless/acb947435fc78d5c06039c7bd5609c735468b0ee.1789002236.git.junjie.cao@intel.com/
Once merged it reaches 7.2.y and Fedora through stable;
I will note here when it lands.

MD11 still tells whether the dynamic path is hit here as
well, so yes to the MTDS rerun, reading the log right
after the reload:

cd /sys/module/acpi/parameters
echo 0xffffffff > trace_debug_layer
echo 0x1c10 > trace_debug_level
printf %s _SB.PCI0.GPP6.WLAN.MTDS > trace_method_name
echo method > trace_state
modprobe -r mt7921e && modprobe mt7921e
sleep 5
echo disable > trace_state
dmesg | grep -E 'Method|RegionField|Value Read' > mtds.txt

The two echo lines are back because the reboot reset
them. Expected: up to 28 reads, MD6G first.

Created attachment 2157575 [details]
ACPI SAR MTDS trace

Thanks Junjie. I reran the trace with MTDS only and attached mtds.txt.

The complete MTDS trace was captured this time. In particular:

MDSE = 0x01
MDSN = 0x02
MD11 = 0x1B

So MD11 is not 0xff.

Let me know if you need any further testing on this machine.

MD11 = 0x1b is 13.5 dBm, a sane limit, so the dynamic
table is fine and the clamp is the geo table alone. The
patch covers that case: a 0xff geo entry falls back to
the dynamic value. Both dynamic tables decode the same:

  range (MHz)   byte       limit
  2402-2494     0x1e       15 dBm
  5150-5350     0x1b       13.5 dBm
  5350-5470     0x1b       13.5 dBm
  5470-5725     0x1a       13 dBm
  5725-5950     0x1a       13 dBm
  5945-7125     0x11-0x12  8.5-9 dBm

With the fix, channel 42 should run at 13.5 dBm (tmac
27) instead of 1.5, and 2.4 GHz at 15 dBm: the limits
ASUS set for this chassis, under the 23 dBm regulatory
cap.

stable: the validate commit was dropped from the 7.2,
6.18, 6.12, 6.6 and 6.1 queues on 2026-09-12, so 7.2.6
is safe for this laptop. The UBSAN line stays until the
skip patch lands.

A Tested-by from this machine would help the patch
along:
https://lore.kernel.org/linux-wireless/acb947435fc78d5c06039c7bd5609c735468b0ee.1789002236.git.junjie.cao@intel.com/
It means loading a rebuilt mt792x-lib module, which
works only with Secure Boot off:

  mokutil --sb-state

If that says disabled (about 300 MB of download, a few
minutes of build; nothing is installed, a reboot
restores the stock module):

sudo dnf install kernel-devel-$(uname -r) gcc make git
git clone --depth 1 --filter=blob:none --sparse -b v$(uname -r | cut -d- -f1) https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git mt76-src
cd mt76-src
git sparse-checkout set drivers/net/wireless/mediatek/mt76
curl -sL https://lore.kernel.org/linux-wireless/acb947435fc78d5c06039c7bd5609c735468b0ee.1789002236.git.junjie.cao@intel.com/t.mbox.gz | gzip -dc | git am
make -j$(nproc) -C /lib/modules/$(uname -r)/build M=$PWD/drivers/net/wireless/mediatek/mt76 modules
sudo modprobe -r mt7921e
sudo modprobe mt76-connac-lib
sudo insmod drivers/net/wireless/mediatek/mt76/mt792x-lib.ko
sudo modprobe mt7921e
sudo cat /sys/kernel/debug/ieee80211/phy0/mt76/txpower_sku
iw dev wlp1s0 info

Wi-Fi drops for a few seconds at the reload. Expected on
channel 42: tmac 27 on the OFDM/HT/VHT/HE rows, and iw
printing 14.00 dBm (it rounds 13.5 up). The unsigned
module taints the kernel; that is normal here.

If it comes out that way, reply on the lore thread above
with a Tested-by line, or say so here and I will add one
with your name and address.

Thanks Junjie. I tested the patch on the ASUS Zenbook 14 UM3406HA with MT7922, using Fedora 44 kernel 7.2.4.

The patch fixes the SAR power clamp as expected.

Before the patch:

iw: txpower 0.00 dBm
OFDM/HT/VHT/HE tmac: 3

With the patched mt76 modules:

iw: txpower 14.00 dBm
OFDM tmac: 27
HT20 tmac: 27
VHT80 tmac: 31

The result is consistent with the ACPI MTDS value MD11 = 0x1b.

Feel free to add my Tested-by.

Let me know if you need any additional testing.

Those are the numbers the tables predict. A second ASUS
owner posted the same result on the list today, Vivobook
S 16 M5606WA: 5 GHz tmac 3 -> 29, TX 6 -> 866 Mbit/s,
with a Tested-by. I will add yours on the thread with a
link to comment 20. The tag needs a name in front of the
address and Bugzilla has none on file for your account,
so please say which one to use ;)

VHT80 tmac 31 next to 27 on the other rows: the driver
sends the same 27 for every OFDM/HT/VHT/HE rate on the
channel, so the 31 is the firmware's own readback, not
the driver's doing.

Next: the patch waits on the mt76 maintainer. Once
applied it reaches 7.2.y through its Fixes tag and
Fedora picks it up from there; the UBSAN line goes with
the separate skip patch, also pending. Nothing more to
test until then. I will note here when either lands.

Thanks Junjie.
My name is Fabien LAGARDE.
You can add the Tested-by with that name.
Thanks again for your help and for working on the fix.

Added on the thread:
https://lore.kernel.org/r/20260914014657.633599-1-junjie.cao@intel.com/

Two of the pending fixes reached mainline on 2026-09-13
(7.3-rc3): the CLC skip patch, 1a296bfd3e77, and the
ACPI SAR probe fix, 7825de3f75d1. I have asked stable to
queue the skip patch together with the bounds check for
7.2.y; once a 7.2.x with both reaches F44 the UBSAN line
is gone. The 7.3-rc1 probe oops from comment 6 is fixed
in rc3 as well; Rawhide has no rc3 build yet. The power
clamp stays until the 0xff patch is applied. Nothing to
test until then.

The CLC pair landed: stable queued both on 2026-09-14
and 7.2.7 (2026-09-21) carries 9417c5818a01 plus the
skip patch. kernel-7.2.7-200.fc44 is in updates-testing
today and already has enough karma for stable, so it
reaches updates within a day:
https://bodhi.fedoraproject.org/updates/FEDORA-2026-ca91e91bf0

On it the UBSAN line is gone and the idx 3 record is
skipped silently. To check after the update:

  sudo journalctl -b -k | grep -E 'UBSAN|CLC'

Expected: no output. An "Invalid CLC record" line
would be new and worth pasting.

The 0xff SAR patch is still unapplied; the power clamp
stays until it lands and reaches 7.2.y. I will note
here when it does.

Tested on Fedora 44 with kernel 7.2.7-200.fc44.x86_64.

The CLC/UBSAN issue is fixed as expected:

sudo journalctl -b -k | grep -E 'UBSAN|CLC'

produces no output.

The SAR power clamp is still present, as expected before the 0xff SAR patch lands. iw reports 0.00 dBm and txpower_sku still shows tmac 3 across the rates.

Thanks!

Tested with Fedora 44 kernel 7.2.9-200.fc44.x86_64.
The UBSAN warning is no longer present at boot.
Wi-Fi is working normally:
signal: -56 dBm
rx bitrate: 720.6 MBit/s
tx bitrate: 600.4 MBit/s
However, iw dev wlp1s0 info still reports:
txpower 0.00 dBm
So the CLC/UBSAN issue appears fixed, while the txpower reporting issue remains.

Tested with Fedora 44 kernel 7.2.10-200.fc44.x86_64.
The previous UBSAN issue remains fixed and Wi-Fi works normally, but iw dev wlp1s0 info still reports txpower 0.00 dBm.

Same issue on an ASUS Zenbook 14 UM3402YA (BIOS UM3402YAR.306, 2024-07-30),
MT7922 [14c3:7922], subsystem AzureWave 1a3b:5300. Fedora 44.

Reproduced on kernel-7.2.10-200.fc44 and kernel-6.19.10-300.fc44, and with
both the current MT7922 firmware (build 20260724, mt7xxx-firmware-20260916)
and the older one (build 20260224, mt7xxx-firmware-20260309). Also unchanged
with mt7921_common disable_clc=1 and mt7921e disable_aspm=1, and with
"iw dev wlp1s0 set txpower fixed 2000".

txpower_sku on channel 155 (5 GHz), all OFDM/HT/VHT/HE rates:
  user   : -1
  eeprom : 34-39
  tmac   : 3
iw reports "txpower 0.00 dBm" on 7.2.10 and "3.00 dBm" on 6.19.10.

The BIOS MTGS table (selected for the MT7922) has 0xFF in every power slot:
  MTGS v1, 3 tables: {FF 00 FF 00 FF 00}, {FF FF FF FF FF FF}, {FF 00 FF 00 FF 00}
The MTDS limits are normal: 0x1E (2.4 GHz), 0x1B (5 GHz), 0x19 (6 GHz).

This matches upstream commit 45f53d98cbaa ("wifi: mt76: mt792x: treat 0xff
ACPI SAR entries as no limit"). In practice, from a desk about 10 m from the
AP, association times out on both 2.4 and 5 GHz, while other machines and
Windows on this same laptop connect fine. Near the AP, it connects with TX
stuck at HE-MCS 1-2.

Please consider backporting this to the F44 7.2.y kernel.

Tested with Fedora 44 kernel 7.2.11-200.fc44.x86_64.
The fix is working on my ASUS Zenbook 14 UM3406HA with the MediaTek MT7922.
Before this kernel:
txpower 0.00 dBm

and txpower_sku showed very low TMAC values, for example:
OFDM (tmac): 3 3 3 3 ...

With kernel 7.2.11:
txpower 14.00 dBm

and the power table now looks normal, for example:
OFDM (tmac): 27 27 27 27 ...
VHT80 (tmac): 31 31 31 ...

The previous UBSAN warning in mt7921_load_clc is also still gone.
So on this machine, both the CLC/UBSAN issue and the ACPI SAR 0xff power clamp issue appear to be fixed with kernel 7.2.11.
Thanks for the fixes and the follow-up.