[regression] mt76x2u: NULL pointer dereference since recent change to fix chanctx emulation for monitor mode

[regression] mt76x2u: NULL pointer dereference since recent change to fix chanctx emulation for monitor mode

[Linux regression tracking (Thorsten Leemhuis)]

Hi, Thorsten here, the Linux kernel's regression tracker.

Johannes, Felix, Lorenzo, Ryder, I noticed a report about a regression
in bugzilla.kernel.org that (for my untrained eyes) appears to be a bug
in some code paths of mt76x2u that was exposed by 0d9c2beed116e6 ("wifi:
mac80211: fix monitor channel with chanctx emulation") [v6.10-rc5,
v6.9.7] from Johannes.

As many (most?) kernel developers don't keep an eye on the bug tracker,
I decided to write this mail. To quote from
https://bugzilla.kernel.org/show_bug.cgi?id=219086 :

>  Michael 2024-07-23 15:38:43 UTC
> 
> After a user opened this discussion:
> https://github.com/ZerBea/hcxdumptool/discussions/465
> 
> Jul 21 05:40:39 rpi4b-aarch kernel: mt76x2u 2-2:1.0 wlan1: entered promiscuous mode
> Jul 21 05:40:45 rpi4b-aarch kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> Jul 21 05:40:45 rpi4b-aarch kernel: Mem abort info:
> Jul 21 05:40:45 rpi4b-aarch kernel:   ESR = 0x0000000096000044
> Jul 21 05:40:45 rpi4b-aarch kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
> Jul 21 05:40:45 rpi4b-aarch kernel:   SET = 0, FnV = 0
> Jul 21 05:40:45 rpi4b-aarch kernel:   EA = 0, S1PTW = 0
> Jul 21 05:40:45 rpi4b-aarch kernel:   FSC = 0x04: level 0 translation fault
> Jul 21 05:40:45 rpi4b-aarch kernel: Data abort info:
> Jul 21 05:40:45 rpi4b-aarch kernel:   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
> Jul 21 05:40:45 rpi4b-aarch kernel:   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> Jul 21 05:40:45 rpi4b-aarch kernel:   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> Jul 21 05:40:45 rpi4b-aarch kernel: user pgtable: 4k pages, 48-bit VAs, pgdp=0000000041300000
> Jul 21 05:40:45 rpi4b-aarch kernel: [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
> Jul 21 05:40:45 rpi4b-aarch kernel: Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP
> 
> I decided to run a test (AMD RYZEN & Arch Linux) on kernel 6.9.10 and 6.10 which confirmed the problem:
> Trying to inject a 802.11 packet caused my AMD systems to become unresponsive.
> I don't have a dmesg log, because my entire system crashed - need to power off!
> 
> To reproduce on kernel 6.9.5 up to 6.10:
> plug in an ALFA AWUS036ACM (mt76x2u)
> set monitor mode
> set WiFi channel and inject a packet
> $ sudo hcxdumptool -i wlp5s0f4u2 --rcascan=active
> or
> sudo ./aireplay-ng --test wlp5s0f4u2
> 
> Kernel 6.6.40 is not affected and the user reported that kernel 6.8.2 is not affected, too.
> That looks like a regression and git bisect identified the commit that caused the problem:
> 
> commit 0d9c2beed116e623ac30810d382bd67163650f98
> Author: Johannes Berg <johannes.berg@intel.com>
> Date:   Wed Jun 12 12:23:51 2024 +0200
> 
>     wifi: mac80211: fix monitor channel with chanctx emulation
>     
>     After the channel context emulation, there were reports that
>     changing the monitor channel no longer works. This is because
>     those drivers don't have WANT_MONITOR_VIF, so the setting the
>     channel always exits out quickly.
>     
>     Fix this by always allocating the virtual monitor sdata, and
>     simply not telling the driver about it unless it wanted to.
>     This way, we have an interface/sdata to bind the chanctx to,
>     and the emulation can work correctly.
>     
>     Cc: stable@vger.kernel.org
>     Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
>     Reported-and-tested-by: Savyasaachi Vanga <savyasaachiv@gmail.com>
>     Closes: https://lore.kernel.org/r/chwoymvpzwtbmzryrlitpwmta5j6mtndocxsyqvdyikqu63lon@gfds653hkknl
>     Link: https://msgid.link/20240612122351.b12d4a109dde.I1831a44417faaab92bea1071209abbe4efbe3fba@changeid
>     Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> 
>  net/mac80211/driver-ops.c | 17 +++++++++++++++++
>  net/mac80211/iface.c      | 21 +++++++++------------
>  net/mac80211/util.c       |  2 +-
>  3 files changed, 27 insertions(+), 13 deletions(-)
> 
> Looks like the patch which should fix monitor mode breaks mt76x2u driver.
> 
> BTW:
> Reasons for me to set severity to high:
> "Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000"
> and
> running a simple command from which I would not have expected that my entire system crashes.
> 
> [tag] [reply] [−]
> Private
> Comment 1 Michael 2024-07-23 17:17:13 UTC
> 
> After some more tests, I'm not longer sure that the problem is caused by the commit mentioned. It looks like it is only a symptom.
> I tested several mt76 devices e.g. this one:
> D 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter
> 
> Driver is mt76x0u:
> $ hcxdumptool -l
>   0	  3	503eaa1a736c	f49da7d6f202	*	wlp48s0f4u2u4   	mt76x0u	NETLINK
> 
> All of them are running into the same problem as mentioned above,
> while other devices are working as expected, e.g.:
> ID 2357:010c TP-Link TL-WN722N v2/v3 [Realtek RTL8188EUS]
> 
> Driver is rtl8xxxu
> $ hcxdumptool -l
>   0	  3	9ca2f4094fe1	c8aacc8562e3	+	wlp48s0f4u2u4   	rtl8xxxu	NETLINK
> 
> This leads me to the assumption that the "chanctx emulation" inside the mt76 series driver caused the real problem.

The reporter is CCed.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

P.S.: let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:

#regzbot introduced: 0d9c2beed116e623ac30810d382bd67163650f98
#regzbot title: net: mt76x2u: NULL pointer dereference since recent
change to fix chanctx emulation for monitor mode
#regzbot from: Michael <ZeroBeat@gmx.de>
#regzbot duplicate: https://bugzilla.kernel.org/show_bug.cgi?id=219086
#regzbot ignore-activity

Re: [regression] mt76x2u: NULL pointer dereference since recent change to fix chanctx emulation for monitor mode

[Johannes Berg]

On Wed, 2024-07-24 at 09:58 +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker.
> 
> Johannes, Felix, Lorenzo, Ryder, I noticed a report about a regression
> in bugzilla.kernel.org that (for my untrained eyes) appears to be a bug
> in some code paths of mt76x2u that was exposed by 0d9c2beed116e6 ("wifi:
> mac80211: fix monitor channel with chanctx emulation") [v6.10-rc5,
> v6.9.7] from Johannes.
> 
> As many (most?) kernel developers don't keep an eye on the bug tracker,
> I decided to write this mail. To quote from
> https://bugzilla.kernel.org/show_bug.cgi?id=219086 :
> 
> >  Michael 2024-07-23 15:38:43 UTC
> > 
> > After a user opened this discussion:
> > https://github.com/ZerBea/hcxdumptool/discussions/465
> > 
> > Jul 21 05:40:39 rpi4b-aarch kernel: mt76x2u 2-2:1.0 wlan1: entered promiscuous mode
> > Jul 21 05:40:45 rpi4b-aarch kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> > Jul 21 05:40:45 rpi4b-aarch kernel: Mem abort info:
> > Jul 21 05:40:45 rpi4b-aarch kernel:   ESR = 0x0000000096000044
> > Jul 21 05:40:45 rpi4b-aarch kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
> > Jul 21 05:40:45 rpi4b-aarch kernel:   SET = 0, FnV = 0
> > Jul 21 05:40:45 rpi4b-aarch kernel:   EA = 0, S1PTW = 0
> > Jul 21 05:40:45 rpi4b-aarch kernel:   FSC = 0x04: level 0 translation fault
> > Jul 21 05:40:45 rpi4b-aarch kernel: Data abort info:
> > Jul 21 05:40:45 rpi4b-aarch kernel:   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
> > Jul 21 05:40:45 rpi4b-aarch kernel:   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> > Jul 21 05:40:45 rpi4b-aarch kernel:   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > Jul 21 05:40:45 rpi4b-aarch kernel: user pgtable: 4k pages, 48-bit VAs, pgdp=0000000041300000
> > 

Not too well-versed with ARM, does that tel me anything about where in
the code the crash was? Without any further information I don't think I
can see anything here, and I don't have an affected device.

johannes

Re: [regression] mt76x2u: NULL pointer dereference since recent change to fix chanctx emulation for monitor mode

[ZeroBeat]

[-- Attachment #1.1.1: Type: text/plain, Size: 2459 bytes --]

If you're interested in, mt7601u is not affected:

EDIMAX EW7711UAn v2

ID 7392:7710 Edimax Technology Co., Ltd Edimax Wi-Fi

$ hcxdumptool -l
   0	  4	74da38f2038e	9e3605d3ab34	*	wlp5s0f4u2      	mt7601u	NETLINK

I haven't figured out yet why it is not affected like the mt76 series.

Michael


Am 24.07.24 um 10:47 schrieb Johannes Berg:
> On Wed, 2024-07-24 at 09:58 +0200, Linux regression tracking (Thorsten
> Leemhuis) wrote:
>> Hi, Thorsten here, the Linux kernel's regression tracker.
>>
>> Johannes, Felix, Lorenzo, Ryder, I noticed a report about a regression
>> in bugzilla.kernel.org that (for my untrained eyes) appears to be a bug
>> in some code paths of mt76x2u that was exposed by 0d9c2beed116e6 ("wifi:
>> mac80211: fix monitor channel with chanctx emulation") [v6.10-rc5,
>> v6.9.7] from Johannes.
>>
>> As many (most?) kernel developers don't keep an eye on the bug tracker,
>> I decided to write this mail. To quote from
>> https://bugzilla.kernel.org/show_bug.cgi?id=219086 :
>>
>>>   Michael 2024-07-23 15:38:43 UTC
>>>
>>> After a user opened this discussion:
>>> https://github.com/ZerBea/hcxdumptool/discussions/465
>>>
>>> Jul 21 05:40:39 rpi4b-aarch kernel: mt76x2u 2-2:1.0 wlan1: entered promiscuous mode
>>> Jul 21 05:40:45 rpi4b-aarch kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
>>> Jul 21 05:40:45 rpi4b-aarch kernel: Mem abort info:
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   ESR = 0x0000000096000044
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   SET = 0, FnV = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   EA = 0, S1PTW = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   FSC = 0x04: level 0 translation fault
>>> Jul 21 05:40:45 rpi4b-aarch kernel: Data abort info:
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel: user pgtable: 4k pages, 48-bit VAs, pgdp=0000000041300000
>>>
> 
> Not too well-versed with ARM, does that tel me anything about where in
> the code the crash was? Without any further information I don't think I
> can see anything here, and I don't have an affected device.
> 
> johannes

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 1705 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [regression] mt76x2u: NULL pointer dereference since recent change to fix chanctx emulation for monitor mode

[ZeroBeat]

[-- Attachment #1.1.1: Type: text/plain, Size: 3112 bytes --]

Just to mention it here. The regression has now reached the longterm kernel:
affected devices: mt76 series (not affected mt7601u)


before update:
$ uname -r
6.6.40-2-lts

$ sudo hcxdumptool -i wlp5s0f4u2 --rcascan=active
^C
38 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
14 PROBERESPONSE(s) captured

exit on sigterm



after update:
$ uname -r
6.6.41-1-lts

$ sudo hcxdumptool -i wlp48s0f4u2u1 --rcascan=active
^C
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
  no transmitter in range
  frames are filtered out by BPF
  driver is broken
Warning: no PROBERESPONSES received (frame injection may not work as expected)
Possible reasons:
  no AP in range
  frames are filtered out by BPF
  driver is broken
  driver does not support frame injection

exit on sigterm


Best regards
Mike






Am 24.07.24 um 10:47 schrieb Johannes Berg:
> On Wed, 2024-07-24 at 09:58 +0200, Linux regression tracking (Thorsten
> Leemhuis) wrote:
>> Hi, Thorsten here, the Linux kernel's regression tracker.
>>
>> Johannes, Felix, Lorenzo, Ryder, I noticed a report about a regression
>> in bugzilla.kernel.org that (for my untrained eyes) appears to be a bug
>> in some code paths of mt76x2u that was exposed by 0d9c2beed116e6 ("wifi:
>> mac80211: fix monitor channel with chanctx emulation") [v6.10-rc5,
>> v6.9.7] from Johannes.
>>
>> As many (most?) kernel developers don't keep an eye on the bug tracker,
>> I decided to write this mail. To quote from
>> https://bugzilla.kernel.org/show_bug.cgi?id=219086 :
>>
>>>   Michael 2024-07-23 15:38:43 UTC
>>>
>>> After a user opened this discussion:
>>> https://github.com/ZerBea/hcxdumptool/discussions/465
>>>
>>> Jul 21 05:40:39 rpi4b-aarch kernel: mt76x2u 2-2:1.0 wlan1: entered promiscuous mode
>>> Jul 21 05:40:45 rpi4b-aarch kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
>>> Jul 21 05:40:45 rpi4b-aarch kernel: Mem abort info:
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   ESR = 0x0000000096000044
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   SET = 0, FnV = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   EA = 0, S1PTW = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   FSC = 0x04: level 0 translation fault
>>> Jul 21 05:40:45 rpi4b-aarch kernel: Data abort info:
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel:   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>>> Jul 21 05:40:45 rpi4b-aarch kernel: user pgtable: 4k pages, 48-bit VAs, pgdp=0000000041300000
>>>
> 
> Not too well-versed with ARM, does that tel me anything about where in
> the code the crash was? Without any further information I don't think I
> can see anything here, and I don't have an affected device.
> 
> johannes

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 1705 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [regression] mt76x2u: NULL pointer dereference since recent change to fix chanctx emulation for monitor mode

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]

> Just to mention it here. The regression has now reached the longterm kernel:
> affected devices: mt76 series (not affected mt7601u)
> 
> 
> before update:
> $ uname -r
> 6.6.40-2-lts
> 
> $ sudo hcxdumptool -i wlp5s0f4u2 --rcascan=active
> ^C
> 38 Packet(s) captured by kernel
> 0 Packet(s) dropped by kernel
> 14 PROBERESPONSE(s) captured
> 
> exit on sigterm
> 
> 
> 
> after update:
> $ uname -r
> 6.6.41-1-lts
> 
> $ sudo hcxdumptool -i wlp48s0f4u2u1 --rcascan=active
> ^C
> 0 Packet(s) captured by kernel
> 0 Packet(s) dropped by kernel
> Warning: too less packets received (monitor mode may not work as expected)
> Possible reasons:
>  no transmitter in range
>  frames are filtered out by BPF
>  driver is broken
> Warning: no PROBERESPONSES received (frame injection may not work as expected)
> Possible reasons:
>  no AP in range
>  frames are filtered out by BPF
>  driver is broken
>  driver does not support frame injection
> 
> exit on sigterm
> 
> 
> Best regards
> Mike

Hi,

I am looking into it. I will get back to you.

Regards,
Lorenzo

> 
> 
> 
> 
> 
> 
> Am 24.07.24 um 10:47 schrieb Johannes Berg:
> > On Wed, 2024-07-24 at 09:58 +0200, Linux regression tracking (Thorsten
> > Leemhuis) wrote:
> > > Hi, Thorsten here, the Linux kernel's regression tracker.
> > > 
> > > Johannes, Felix, Lorenzo, Ryder, I noticed a report about a regression
> > > in bugzilla.kernel.org that (for my untrained eyes) appears to be a bug
> > > in some code paths of mt76x2u that was exposed by 0d9c2beed116e6 ("wifi:
> > > mac80211: fix monitor channel with chanctx emulation") [v6.10-rc5,
> > > v6.9.7] from Johannes.
> > > 
> > > As many (most?) kernel developers don't keep an eye on the bug tracker,
> > > I decided to write this mail. To quote from
> > > https://bugzilla.kernel.org/show_bug.cgi?id=219086 :
> > > 
> > > >   Michael 2024-07-23 15:38:43 UTC
> > > > 
> > > > After a user opened this discussion:
> > > > https://github.com/ZerBea/hcxdumptool/discussions/465
> > > > 
> > > > Jul 21 05:40:39 rpi4b-aarch kernel: mt76x2u 2-2:1.0 wlan1: entered promiscuous mode
> > > > Jul 21 05:40:45 rpi4b-aarch kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> > > > Jul 21 05:40:45 rpi4b-aarch kernel: Mem abort info:
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   ESR = 0x0000000096000044
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   SET = 0, FnV = 0
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   EA = 0, S1PTW = 0
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   FSC = 0x04: level 0 translation fault
> > > > Jul 21 05:40:45 rpi4b-aarch kernel: Data abort info:
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> > > > Jul 21 05:40:45 rpi4b-aarch kernel:   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> > > > Jul 21 05:40:45 rpi4b-aarch kernel: user pgtable: 4k pages, 48-bit VAs, pgdp=0000000041300000
> > > > 
> > 
> > Not too well-versed with ARM, does that tel me anything about where in
> > the code the crash was? Without any further information I don't think I
> > can see anything here, and I don't have an affected device.
> > 
> > johannes






[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [regression] mt76x2u: NULL pointer dereference since recent change to fix chanctx emulation for monitor mode

[ZeroBeat]

[-- Attachment #1.1.1: Type: text/plain, Size: 3555 bytes --]

I've added several debug printk - no luck, yet.

Regards
Mike


Am 25.07.24 um 17:57 schrieb Lorenzo Bianconi:
>> Just to mention it here. The regression has now reached the longterm kernel:
>> affected devices: mt76 series (not affected mt7601u)
>>
>>
>> before update:
>> $ uname -r
>> 6.6.40-2-lts
>>
>> $ sudo hcxdumptool -i wlp5s0f4u2 --rcascan=active
>> ^C
>> 38 Packet(s) captured by kernel
>> 0 Packet(s) dropped by kernel
>> 14 PROBERESPONSE(s) captured
>>
>> exit on sigterm
>>
>>
>>
>> after update:
>> $ uname -r
>> 6.6.41-1-lts
>>
>> $ sudo hcxdumptool -i wlp48s0f4u2u1 --rcascan=active
>> ^C
>> 0 Packet(s) captured by kernel
>> 0 Packet(s) dropped by kernel
>> Warning: too less packets received (monitor mode may not work as expected)
>> Possible reasons:
>>   no transmitter in range
>>   frames are filtered out by BPF
>>   driver is broken
>> Warning: no PROBERESPONSES received (frame injection may not work as expected)
>> Possible reasons:
>>   no AP in range
>>   frames are filtered out by BPF
>>   driver is broken
>>   driver does not support frame injection
>>
>> exit on sigterm
>>
>>
>> Best regards
>> Mike
> 
> Hi,
> 
> I am looking into it. I will get back to you.
> 
> Regards,
> Lorenzo
> 
>>
>>
>>
>>
>>
>>
>> Am 24.07.24 um 10:47 schrieb Johannes Berg:
>>> On Wed, 2024-07-24 at 09:58 +0200, Linux regression tracking (Thorsten
>>> Leemhuis) wrote:
>>>> Hi, Thorsten here, the Linux kernel's regression tracker.
>>>>
>>>> Johannes, Felix, Lorenzo, Ryder, I noticed a report about a regression
>>>> in bugzilla.kernel.org that (for my untrained eyes) appears to be a bug
>>>> in some code paths of mt76x2u that was exposed by 0d9c2beed116e6 ("wifi:
>>>> mac80211: fix monitor channel with chanctx emulation") [v6.10-rc5,
>>>> v6.9.7] from Johannes.
>>>>
>>>> As many (most?) kernel developers don't keep an eye on the bug tracker,
>>>> I decided to write this mail. To quote from
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=219086 :
>>>>
>>>>>    Michael 2024-07-23 15:38:43 UTC
>>>>>
>>>>> After a user opened this discussion:
>>>>> https://github.com/ZerBea/hcxdumptool/discussions/465
>>>>>
>>>>> Jul 21 05:40:39 rpi4b-aarch kernel: mt76x2u 2-2:1.0 wlan1: entered promiscuous mode
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel: Mem abort info:
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   ESR = 0x0000000096000044
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   SET = 0, FnV = 0
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   EA = 0, S1PTW = 0
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   FSC = 0x04: level 0 translation fault
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel: Data abort info:
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel:   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>>>>> Jul 21 05:40:45 rpi4b-aarch kernel: user pgtable: 4k pages, 48-bit VAs, pgdp=0000000041300000
>>>>>
>>>
>>> Not too well-versed with ARM, does that tel me anything about where in
>>> the code the crash was? Without any further information I don't think I
>>> can see anything here, and I don't have an affected device.
>>>
>>> johannes
> 
> 
> 
> 
> 

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 1705 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]