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

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

[Alexander Wilhelm]

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
little‑endian first, then copy it into the target array.

Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
---
 drivers/net/wireless/ath/ath12k/dp.h | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath12k/dp.h b/drivers/net/wireless/ath/ath12k/dp.h
index f8cfc7bb29dd..50957915dbf4 100644
--- a/drivers/net/wireless/ath/ath12k/dp.h
+++ b/drivers/net/wireless/ath/ath12k/dp.h
@@ -647,8 +647,11 @@ int ath12k_dp_arch_rx_tid_delete_handler(struct ath12k_dp *dp,
 
 static inline void ath12k_dp_get_mac_addr(u32 addr_l32, u16 addr_h16, u8 *addr)
 {
-	memcpy(addr, &addr_l32, 4);
-	memcpy(addr + 4, &addr_h16, ETH_ALEN - 4);
+	__le32 le_addr_l32 = cpu_to_le32(addr_l32);
+	__le16 le_addr_h16 = cpu_to_le16(addr_h16);
+
+	memcpy(addr, &le_addr_l32, 4);
+	memcpy(addr + 4, &le_addr_h16, ETH_ALEN - 4);
 }
 
 static inline struct ath12k_dp *

---
base-commit: 702847e8cfd51856836a282db2073defd7cfd80c
change-id: 20260317-fix-mac-addr-copy-on-big-endian-f1a4fea40184

Best regards,
-- 
Alexander Wilhelm <alexander.wilhelm@westermo.com>

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

[Baochen Qiang]

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?

> little‑endian first, then copy it into the target array.
> 
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
> ---
>  drivers/net/wireless/ath/ath12k/dp.h | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/dp.h b/drivers/net/wireless/ath/ath12k/dp.h
> index f8cfc7bb29dd..50957915dbf4 100644
> --- a/drivers/net/wireless/ath/ath12k/dp.h
> +++ b/drivers/net/wireless/ath/ath12k/dp.h
> @@ -647,8 +647,11 @@ int ath12k_dp_arch_rx_tid_delete_handler(struct ath12k_dp *dp,
>  
>  static inline void ath12k_dp_get_mac_addr(u32 addr_l32, u16 addr_h16, u8 *addr)
>  {
> -	memcpy(addr, &addr_l32, 4);
> -	memcpy(addr + 4, &addr_h16, ETH_ALEN - 4);
> +	__le32 le_addr_l32 = cpu_to_le32(addr_l32);
> +	__le16 le_addr_h16 = cpu_to_le16(addr_h16);
> +
> +	memcpy(addr, &le_addr_l32, 4);
> +	memcpy(addr + 4, &le_addr_h16, ETH_ALEN - 4);
>  }
>  
>  static inline struct ath12k_dp *
> 
> ---
> base-commit: 702847e8cfd51856836a282db2073defd7cfd80c
> change-id: 20260317-fix-mac-addr-copy-on-big-endian-f1a4fea40184
> 
> Best regards,

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

[Alexander Wilhelm]

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

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

[Alexander Wilhelm]

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