Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: On an ASUS Zenbook 14 UM3406HA with a MediaTek MT7922 Wi-Fi adapter (PCI ID 14c3:0616, subsystem 105b:e0de), the mt7921e driver triggers a reproducible UBSAN array-index-out-of-bounds warning during firmware initialization after updating to linux-firmware/mt7xxx-firmware 20260810-1.fc44. The warning is: 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]' The call trace contains: mt7921_load_clc mt7921_run_firmware mt7921e_mcu_init mt7921_init_work The new firmware reports: HW/SW Version: 0x8a108a10 Build Time: 20260724143257a WM Firmware Version: ____000000 Build Time: 20260724143402 With the previous firmware (Build Time 20260605203307a / 20260605203411), this UBSAN warning was not present. Despite the warning, the adapter initializes successfully and Wi-Fi currently works normally. There are no subsequent mt7921 reset, timeout, crash or connection errors. There is also an apparently unrelated txpower reporting issue: "iw dev wlp1s0 info" always reports: txpower 3.00 dBm even after: sudo iw dev wlp1s0 set txpower auto The regulatory domain is correctly set to France (FR), and the currently used channel 40 / 5200 MHz has a regulatory maximum of 23 dBm. Actual Wi-Fi performance does not appear consistent with a real 3 dBm transmit-power limitation. 2. What is the Version-Release number of the kernel: 7.1.8-200.fc44.x86_64 Relevant packages: linux-firmware-20260810-1.fc44.noarch mt7xxx-firmware-20260810-1.fc44.noarch NetworkManager-1.56.1-2.fc44.x86_64 iw-6.17-2.fc44.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? The UBSAN warning was not present on the immediately previous boot using the older MediaTek firmware built on 2026-06-05. After installing linux-firmware/mt7xxx-firmware 20260810-1.fc44, which loads the MediaTek firmware built on 2026-07-24, the UBSAN warning appears at boot with kernel 7.1.8-200.fc44.x86_64. Therefore the UBSAN warning appears correlated with the firmware update. I have not yet tested the new firmware with an older Fedora kernel. The txpower 3.00 dBm reporting issue predates this firmware update. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes. 1. Boot Fedora 44 with kernel 7.1.8-200.fc44.x86_64 and mt7xxx-firmware-20260810-1.fc44. 2. Check the kernel log: sudo journalctl -b -k --no-pager | grep -A40 -B10 'UBSAN' 3. The UBSAN warning appears during mt7921 firmware initialization: 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]' The issue reproduces at boot with the new firmware. 5. Does this problem occur with the latest Rawhide kernel? Not tested. I am currently running Fedora 44 stable and have not installed a Rawhide kernel. 6. Are you running any modules that not shipped with directly Fedora's kernel? No third-party/out-of-tree module is knowingly used for the MediaTek MT7922 adapter. The adapter uses the Fedora kernel mt7921e module. 7. Please attach the kernel logs. I will attach the complete kernel log from the affected boot, generated with: sudo journalctl --no-hostname -k -b > dmesg.txt Reproducible: Always
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