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.