Re: [PATCH] wifi: ath12k: fix MAC address copy on big endian

[Alexander Wilhelm <alexander.wilhelm@westermo.com>]

On Thu, Mar 19, 2026 at 08:01:31AM +0100, Alexander Wilhelm wrote:
> On Thu, Mar 19, 2026 at 11:00:22AM +0800, Baochen Qiang wrote:
> > 
> > 
> > On 3/17/2026 7:22 PM, Alexander Wilhelm wrote:
> > > The ath12k_dp_get_mac_addr function performs a simple memcpy from a
> > > CPU-native data types into an u8 array. On a big-endian architecture, this
> > > later results in a null‑pointer dereference. Convert the data to
> > 
> > curious how could this happen? how matter the endian, it is just six bytes which are not a
> > pointer hence can not be dereferenced, no?
> 
> You are right, the wrong shuffling of the MAC address on big-endian platform
> itself does not immediately cause the null-pointer dereference. But later in the
> code execution this address is used, which does lead to a null pointer. The
> execution do not handle the error and continues despite the null pointer, so
> this may be an additional bug. I need some time to find the exact location
> again, but here are the logs that show the triggered null-pointer dereference:
> 
>     user@host:~# hostapd /mnt/custom/hostapd.conf
>     Kernel attempted to read user page (8) - exploit attempt? (uid: 0)
>     BUG: Kernel NULL pointer dereference on read at 0x00000008
>     Faulting instruction address: 0xe2077f38
>     Oops: Kernel access of bad area, sig: 11 [#1]
>     BE PAGE_SIZE=4K SMP NR_CPUS=4 CoreNet Generic
>     Modules linked in: ath12k(O) mac80211(O) cfg80211(O) compat(O) ...
>     CPU: 1 PID: 8455 Comm: hostapd Tainted: G           O       6.6.73 #0
>     Hardware name: CyBoxAP-A e5500 0x80241021 CoreNet Generic
>     NIP:  e2077f38 LR: e2077e74 CTR: c00833f0
>     REGS: d0e7bac0 TRAP: 0300   Tainted: G           O        (6.6.73)
>     MSR:  0002b002 <CE,EE,FP,ME>  CR: 28004484  XER: 00000000
>     DEAR: 00000008 ESR: 00000000
>     GPR00: e2077e74 d0e7bbb0 c1dc4a00 00000000 0002b002 00000058 0934edc0 001c0000 
>     GPR08: d0e7bb58 00000000 c9370948 00000000 c00833f0 035012ac 00000000 04e04690 
>     GPR16: 00000000 00000000 00000000 bf9d2070 00000000 03493d36 04e04660 c9349600 
>     GPR24: 00000000 00000000 00000000 c8b1d1f8 c8b1d248 d09917c0 c8b1d614 0000000e 
>     NIP [e2077f38] ath12k_mac_11d_scan_stop+0x1c98/0x31d0 [ath12k]
>     LR [e2077e74] ath12k_mac_11d_scan_stop+0x1bd4/0x31d0 [ath12k]
>     Call Trace:
>     [d0e7bbb0] [e2077e74] ath12k_mac_11d_scan_stop+0x1bd4/0x31d0 [ath12k] (unreliable)
>     [d0e7bc10] [e20793b4] ath12k_mac_11d_scan_stop+0x3114/0x31d0 [ath12k]
>     [d0e7bc40] [e1f5b41c] ieee80211_do_open+0x13c/0x8b0 [mac80211]
>     [d0e7bc70] [e1f5bb40] ieee80211_do_open+0x860/0x8b0 [mac80211]
>     [d0e7bc90] [c0675318] __dev_open+0x108/0x1c0
>     [d0e7bcc0] [c06758ac] __dev_change_flags+0x1dc/0x270
>     [d0e7bd00] [c067596c] dev_change_flags+0x2c/0x90
>     [d0e7bd20] [c0774838] devinet_ioctl+0x2c8/0x990
>     [d0e7bd80] [c0776f60] inet_ioctl+0x1a0/0x270
>     [d0e7be00] [c0639750] sock_ioctl+0xa0/0x580
>     [d0e7be60] [c02042c4] sys_ioctl+0x4e4/0xc90
>     [d0e7bee0] [c000dbac] system_call_exception+0xac/0x1f0
>     [d0e7bf00] [c00110e8] ret_from_syscall+0x0/0x28
>     --- interrupt: c00 at 0x2ad109c
>     NIP:  02ad109c LR: 02bc3958 CTR: c0249eb0
>     REGS: d0e7bf10 TRAP: 0c00   Tainted: G           O        (6.6.73)
>     MSR:  0002d002 <CE,EE,PR,ME>  CR: 88004400  XER: 20000000
> 
>     GPR00: 00000036 bf9d1c60 98425520 00000007 00008914 bf9d1ca0 00000002 bf9d1c98 
>     GPR08: 00000007 033b3d68 04e062c0 d0e7bf00 22002800 035012ac 00000000 04e04690 
>     GPR16: 00000000 00000000 00000000 bf9d2070 00000000 03493d36 04e04660 00000000 
>     GPR24: 00000000 bf9d1cf0 04e0af40 00000001 bf9d1ca0 00000007 02bc3958 00000000 
>     NIP [02ad109c] 0x2ad109c
>     LR [02bc3958] 0x2bc3958
>     --- interrupt: c00
>    Code: 4bfeee39 77e91000 40c200fc 77e92000 41c20018 813b0000 28090003 41c207fc 28090002 41c20834 833e001c 835c0140 <81390008> 2c1a0000 80690000 40c2031c
>     ---[ end trace 0000000000000000 ]---
> 
>     Kernel panic - not syncing: Fatal exception
>     ---[ end Kernel panic - not syncing: Fatal exception ]---
> 
> 
> Best regards
> Alexander Wilhelm

Unfortunately, I currently don’t have the device available to test ath12k on
big‑endian now. Nevertheless, I tried to reproduce the same issue on ath11k.
Interestingly, I don’t even reach the null pointer dereference step. Already
when starting the device, I get the following error message:

    user@host-A:~# ip link set wlan0 up
    RTNETLINK answers: Connection timed out

When I have access to the device again, I can investigate the null-pointer issue
in more detail. Until then, you have the logs above, maybe they already help.


Best regards
Alexander Wilhelm