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

[PATCH RESEND] 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 RESEND] wifi: ath12k: fix MAC address copy on big endian

[Baochen Qiang]

On 6/29/2026 3:55 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

Alex, did you find a time to investigate the root cause of the null pointer?

> 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 RESEND] wifi: ath12k: fix MAC address copy on big endian

[Alexander Wilhelm]

On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
> 
> 
> On 6/29/2026 3:55 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
> 
> Alex, did you find a time to investigate the root cause of the null pointer?

Sorry, I haven't had a chance to look into it yet. However, it's on my to-do
list. I will try to reproduce the issue again as soon as possible.


Best regards
Alexander Wilhelm

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

[Alexander Wilhelm]

On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
> > 
> > 
> > On 6/29/2026 3:55 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
> > 
> > Alex, did you find a time to investigate the root cause of the null pointer?

Hi Baochen,

I am now running kernel v6.18.26, and it looks like the null-pointer issue is
gone. I only see the following log messages:

    ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
    ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
    ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
    ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0

Should I rebase the patch onto the latest `ath/master` branch and update the
commit description accordingly?


Best regards
Alexander Wilhelm

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

[Baochen Qiang]

On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
> On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
>> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
>>>
>>>
>>> On 6/29/2026 3:55 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
>>>
>>> Alex, did you find a time to investigate the root cause of the null pointer?
> 
> Hi Baochen,
> 
> I am now running kernel v6.18.26, and it looks like the null-pointer issue is
> gone. I only see the following log messages:
> 
>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110

what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
is that, without this patch (if we really need it) we get a wrong mac addr, then in
ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
create a new peer and wakeup the waiting thread. But the log here clearly indicates that
the wait timeout, which does not make sense to me.

>     ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
>     ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
>     ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
> 
> Should I rebase the patch onto the latest `ath/master` branch and update the
> commit description accordingly?
> 
> 
> Best regards
> Alexander Wilhelm

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

[Alexander Wilhelm]

On Thu, Jul 02, 2026 at 05:56:01PM +0800, Baochen Qiang wrote:
> 
> 
> On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
> > On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
> >> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
> >>>
> >>>
> >>> On 6/29/2026 3:55 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
> >>>
> >>> Alex, did you find a time to investigate the root cause of the null pointer?
> > 
> > Hi Baochen,
> > 
> > I am now running kernel v6.18.26, and it looks like the null-pointer issue is
> > gone. I only see the following log messages:
> > 
> >     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
> 
> what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
> is that, without this patch (if we really need it) we get a wrong mac addr, then in
> ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
> create a new peer and wakeup the waiting thread. But the log here clearly indicates that
> the wait timeout, which does not make sense to me.

I have now added the following debug output for `peer_map_ev` inside of
`ath12k_dp_htt_htc_t2h_msg_handler`:

    /* DEBUG */
    switch (type) {
    case HTT_T2H_MSG_TYPE_PEER_MAP:
    case HTT_T2H_MSG_TYPE_PEER_MAP2:
    case HTT_T2H_MSG_TYPE_PEER_MAP3:
        ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info: %08X\n", le32_to_cpu(resp->peer_map_ev.info));
        ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.mac_addr_l32: %08X\n", le32_to_cpu(resp->peer_map_ev.mac_addr_l32));
        ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info1: %08X\n", le32_to_cpu(resp->peer_map_ev.info1));
        ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info2: %08X\n", le32_to_cpu(resp->peer_map_ev.info2));
        break;
    default:
        break;
    }

Here is the result:

    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
    ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
    ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
    ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
    ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0

Let me know if you see anything suspicious or if you need additional debug
information.


Best regards
Alexander Wilhelm

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

[Baochen Qiang]

On 7/2/2026 8:06 PM, Alexander Wilhelm wrote:
> On Thu, Jul 02, 2026 at 05:56:01PM +0800, Baochen Qiang wrote:
>>
>>
>> On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
>>> On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
>>>> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
>>>>>
>>>>>
>>>>> On 6/29/2026 3:55 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
>>>>>
>>>>> Alex, did you find a time to investigate the root cause of the null pointer?
>>>
>>> Hi Baochen,
>>>
>>> I am now running kernel v6.18.26, and it looks like the null-pointer issue is
>>> gone. I only see the following log messages:
>>>
>>>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
>>
>> what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
>> is that, without this patch (if we really need it) we get a wrong mac addr, then in
>> ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
>> create a new peer and wakeup the waiting thread. But the log here clearly indicates that
>> the wait timeout, which does not make sense to me.

I think I can understand the behavior here: even if wakeup happens, the waiter in
ath12k_wait_for_dp_link_peer_common() checks the map result by calling
ath12k_dp_link_peer_find_by_vdev_and_addr(). Since the mac addr of the newly created peer
does not match, check failed. Finally we get timeout.

> 
> I have now added the following debug output for `peer_map_ev` inside of
> `ath12k_dp_htt_htc_t2h_msg_handler`:
> 
>     /* DEBUG */
>     switch (type) {
>     case HTT_T2H_MSG_TYPE_PEER_MAP:
>     case HTT_T2H_MSG_TYPE_PEER_MAP2:
>     case HTT_T2H_MSG_TYPE_PEER_MAP3:
>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info: %08X\n", le32_to_cpu(resp->peer_map_ev.info));
>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.mac_addr_l32: %08X\n", le32_to_cpu(resp->peer_map_ev.mac_addr_l32));
>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info1: %08X\n", le32_to_cpu(resp->peer_map_ev.info1));
>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info2: %08X\n", le32_to_cpu(resp->peer_map_ev.info2));
>         break;
>     default:
>         break;
>     }
> 
> Here is the result:
> 
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
>     ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
>     ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
>     ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
> 
> Let me know if you see anything suspicious or if you need additional debug
> information.

I am not really sure about the final mac addr and vdev id passed to
ath12k_dp_link_peer_map_event(), so can you also add print below?

diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c
b/drivers/net/wireless/ath/ath12k/dp_peer.c
index 47d009a0d61f..3e8201d536a5 100644
--- a/drivers/net/wireless/ath/ath12k/dp_peer.c
+++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
@@ -162,6 +162,9 @@ void ath12k_dp_link_peer_map_event(struct ath12k_base *ab, u8 vdev_id,
u16 peer_
        struct ath12k_dp *dp = ath12k_ab_to_dp(ab);
        struct ath12k *ar;

+       pr_info("peer map event: vdev_id %u peer_id %u mac_addr %pM ast_hash %u hw_peer_id
%u\n",
+               vdev_id, peer_id, mac_addr, ast_hash, hw_peer_id);
+
        spin_lock_bh(&dp->dp_lock);
        peer = ath12k_dp_link_peer_find_by_vdev_and_addr(dp, vdev_id, mac_addr);
        if (!peer) {


> 
> 
> Best regards
> Alexander Wilhelm

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

[Alexander Wilhelm]

On Fri, Jul 03, 2026 at 12:04:10PM +0800, Baochen Qiang wrote:
> 
> 
> On 7/2/2026 8:06 PM, Alexander Wilhelm wrote:
> > On Thu, Jul 02, 2026 at 05:56:01PM +0800, Baochen Qiang wrote:
> >>
> >>
> >> On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
> >>> On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
> >>>> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
> >>>>>
> >>>>>
> >>>>> On 6/29/2026 3:55 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
> >>>>>
> >>>>> Alex, did you find a time to investigate the root cause of the null pointer?
> >>>
> >>> Hi Baochen,
> >>>
> >>> I am now running kernel v6.18.26, and it looks like the null-pointer issue is
> >>> gone. I only see the following log messages:
> >>>
> >>>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
> >>
> >> what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
> >> is that, without this patch (if we really need it) we get a wrong mac addr, then in
> >> ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
> >> create a new peer and wakeup the waiting thread. But the log here clearly indicates that
> >> the wait timeout, which does not make sense to me.
> 
> I think I can understand the behavior here: even if wakeup happens, the waiter in
> ath12k_wait_for_dp_link_peer_common() checks the map result by calling
> ath12k_dp_link_peer_find_by_vdev_and_addr(). Since the mac addr of the newly created peer
> does not match, check failed. Finally we get timeout.
> 
> > 
> > I have now added the following debug output for `peer_map_ev` inside of
> > `ath12k_dp_htt_htc_t2h_msg_handler`:
> > 
> >     /* DEBUG */
> >     switch (type) {
> >     case HTT_T2H_MSG_TYPE_PEER_MAP:
> >     case HTT_T2H_MSG_TYPE_PEER_MAP2:
> >     case HTT_T2H_MSG_TYPE_PEER_MAP3:
> >         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info: %08X\n", le32_to_cpu(resp->peer_map_ev.info));
> >         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.mac_addr_l32: %08X\n", le32_to_cpu(resp->peer_map_ev.mac_addr_l32));
> >         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info1: %08X\n", le32_to_cpu(resp->peer_map_ev.info1));
> >         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info2: %08X\n", le32_to_cpu(resp->peer_map_ev.info2));
> >         break;
> >     default:
> >         break;
> >     }
> > 
> > Here is the result:
> > 
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
> >     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
> >     ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
> >     ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
> >     ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
> > 
> > Let me know if you see anything suspicious or if you need additional debug
> > information.
> 
> I am not really sure about the final mac addr and vdev id passed to
> ath12k_dp_link_peer_map_event(), so can you also add print below?
> 
> diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c
> b/drivers/net/wireless/ath/ath12k/dp_peer.c
> index 47d009a0d61f..3e8201d536a5 100644
> --- a/drivers/net/wireless/ath/ath12k/dp_peer.c
> +++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
> @@ -162,6 +162,9 @@ void ath12k_dp_link_peer_map_event(struct ath12k_base *ab, u8 vdev_id,
> u16 peer_
>         struct ath12k_dp *dp = ath12k_ab_to_dp(ab);
>         struct ath12k *ar;
> 
> +       pr_info("peer map event: vdev_id %u peer_id %u mac_addr %pM ast_hash %u hw_peer_id
> %u\n",
> +               vdev_id, peer_id, mac_addr, ast_hash, hw_peer_id);
> +
>         spin_lock_bh(&dp->dp_lock);
>         peer = ath12k_dp_link_peer_find_by_vdev_and_addr(dp, vdev_id, mac_addr);
>         if (!peer) {

Sure, here is the output:

    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
    ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
    peer map event: vdev_id 0 peer_id 2 mac_addr d902298bM ast_hash 5 hw_peer_id 757
    ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
    ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
    ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
    ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0


Best regards
Alexander Wilhelm

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

[Baochen Qiang]

On 7/3/2026 2:36 PM, Alexander Wilhelm wrote:
> On Fri, Jul 03, 2026 at 12:04:10PM +0800, Baochen Qiang wrote:
>>
>>
>> On 7/2/2026 8:06 PM, Alexander Wilhelm wrote:
>>> On Thu, Jul 02, 2026 at 05:56:01PM +0800, Baochen Qiang wrote:
>>>>
>>>>
>>>> On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
>>>>> On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
>>>>>> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 6/29/2026 3:55 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
>>>>>>>
>>>>>>> Alex, did you find a time to investigate the root cause of the null pointer?
>>>>>
>>>>> Hi Baochen,
>>>>>
>>>>> I am now running kernel v6.18.26, and it looks like the null-pointer issue is
>>>>> gone. I only see the following log messages:
>>>>>
>>>>>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
>>>>
>>>> what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
>>>> is that, without this patch (if we really need it) we get a wrong mac addr, then in
>>>> ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
>>>> create a new peer and wakeup the waiting thread. But the log here clearly indicates that
>>>> the wait timeout, which does not make sense to me.
>>
>> I think I can understand the behavior here: even if wakeup happens, the waiter in
>> ath12k_wait_for_dp_link_peer_common() checks the map result by calling
>> ath12k_dp_link_peer_find_by_vdev_and_addr(). Since the mac addr of the newly created peer
>> does not match, check failed. Finally we get timeout.
>>
>>>
>>> I have now added the following debug output for `peer_map_ev` inside of
>>> `ath12k_dp_htt_htc_t2h_msg_handler`:
>>>
>>>     /* DEBUG */
>>>     switch (type) {
>>>     case HTT_T2H_MSG_TYPE_PEER_MAP:
>>>     case HTT_T2H_MSG_TYPE_PEER_MAP2:
>>>     case HTT_T2H_MSG_TYPE_PEER_MAP3:
>>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info: %08X\n", le32_to_cpu(resp->peer_map_ev.info));
>>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.mac_addr_l32: %08X\n", le32_to_cpu(resp->peer_map_ev.mac_addr_l32));
>>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info1: %08X\n", le32_to_cpu(resp->peer_map_ev.info1));
>>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info2: %08X\n", le32_to_cpu(resp->peer_map_ev.info2));
>>>         break;
>>>     default:
>>>         break;
>>>     }
>>>
>>> Here is the result:
>>>
>>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
>>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
>>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
>>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
>>>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
>>>     ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
>>>     ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
>>>     ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
>>>
>>> Let me know if you see anything suspicious or if you need additional debug
>>> information.
>>
>> I am not really sure about the final mac addr and vdev id passed to
>> ath12k_dp_link_peer_map_event(), so can you also add print below?
>>
>> diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c
>> b/drivers/net/wireless/ath/ath12k/dp_peer.c
>> index 47d009a0d61f..3e8201d536a5 100644
>> --- a/drivers/net/wireless/ath/ath12k/dp_peer.c
>> +++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
>> @@ -162,6 +162,9 @@ void ath12k_dp_link_peer_map_event(struct ath12k_base *ab, u8 vdev_id,
>> u16 peer_
>>         struct ath12k_dp *dp = ath12k_ab_to_dp(ab);
>>         struct ath12k *ar;
>>
>> +       pr_info("peer map event: vdev_id %u peer_id %u mac_addr %pM ast_hash %u hw_peer_id
>> %u\n",
>> +               vdev_id, peer_id, mac_addr, ast_hash, hw_peer_id);
>> +
>>         spin_lock_bh(&dp->dp_lock);
>>         peer = ath12k_dp_link_peer_find_by_vdev_and_addr(dp, vdev_id, mac_addr);
>>         if (!peer) {
> 
> Sure, here is the output:
> 
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
>     peer map event: vdev_id 0 peer_id 2 mac_addr d902298bM ast_hash 5 hw_peer_id 757

what is d902298bM? are you using Linux? seems %pM is not properly formatted in your
environment.

>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
>     ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
>     ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
>     ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
> 
> 
> Best regards
> Alexander Wilhelm

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

[Alexander Wilhelm]

On Fri, Jul 03, 2026 at 03:10:23PM +0800, Baochen Qiang wrote:
> 
> 
> On 7/3/2026 2:36 PM, Alexander Wilhelm wrote:
> > On Fri, Jul 03, 2026 at 12:04:10PM +0800, Baochen Qiang wrote:
> >>
> >>
> >> On 7/2/2026 8:06 PM, Alexander Wilhelm wrote:
> >>> On Thu, Jul 02, 2026 at 05:56:01PM +0800, Baochen Qiang wrote:
> >>>>
> >>>>
> >>>> On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
> >>>>> On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
> >>>>>> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 6/29/2026 3:55 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
> >>>>>>>
> >>>>>>> Alex, did you find a time to investigate the root cause of the null pointer?
> >>>>>
> >>>>> Hi Baochen,
> >>>>>
> >>>>> I am now running kernel v6.18.26, and it looks like the null-pointer issue is
> >>>>> gone. I only see the following log messages:
> >>>>>
> >>>>>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
> >>>>
> >>>> what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
> >>>> is that, without this patch (if we really need it) we get a wrong mac addr, then in
> >>>> ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
> >>>> create a new peer and wakeup the waiting thread. But the log here clearly indicates that
> >>>> the wait timeout, which does not make sense to me.
> >>
> >> I think I can understand the behavior here: even if wakeup happens, the waiter in
> >> ath12k_wait_for_dp_link_peer_common() checks the map result by calling
> >> ath12k_dp_link_peer_find_by_vdev_and_addr(). Since the mac addr of the newly created peer
> >> does not match, check failed. Finally we get timeout.
> >>
> >>>
> >>> I have now added the following debug output for `peer_map_ev` inside of
> >>> `ath12k_dp_htt_htc_t2h_msg_handler`:
> >>>
> >>>     /* DEBUG */
> >>>     switch (type) {
> >>>     case HTT_T2H_MSG_TYPE_PEER_MAP:
> >>>     case HTT_T2H_MSG_TYPE_PEER_MAP2:
> >>>     case HTT_T2H_MSG_TYPE_PEER_MAP3:
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info: %08X\n", le32_to_cpu(resp->peer_map_ev.info));
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.mac_addr_l32: %08X\n", le32_to_cpu(resp->peer_map_ev.mac_addr_l32));
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info1: %08X\n", le32_to_cpu(resp->peer_map_ev.info1));
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info2: %08X\n", le32_to_cpu(resp->peer_map_ev.info2));
> >>>         break;
> >>>     default:
> >>>         break;
> >>>     }
> >>>
> >>> Here is the result:
> >>>
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
> >>>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
> >>>     ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
> >>>     ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
> >>>     ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
> >>>
> >>> Let me know if you see anything suspicious or if you need additional debug
> >>> information.
> >>
> >> I am not really sure about the final mac addr and vdev id passed to
> >> ath12k_dp_link_peer_map_event(), so can you also add print below?
> >>
> >> diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> b/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> index 47d009a0d61f..3e8201d536a5 100644
> >> --- a/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> +++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> @@ -162,6 +162,9 @@ void ath12k_dp_link_peer_map_event(struct ath12k_base *ab, u8 vdev_id,
> >> u16 peer_
> >>         struct ath12k_dp *dp = ath12k_ab_to_dp(ab);
> >>         struct ath12k *ar;
> >>
> >> +       pr_info("peer map event: vdev_id %u peer_id %u mac_addr %pM ast_hash %u hw_peer_id
> >> %u\n",
> >> +               vdev_id, peer_id, mac_addr, ast_hash, hw_peer_id);
> >> +
> >>         spin_lock_bh(&dp->dp_lock);
> >>         peer = ath12k_dp_link_peer_find_by_vdev_and_addr(dp, vdev_id, mac_addr);
> >>         if (!peer) {
> > 
> > Sure, here is the output:
> > 
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
> >     peer map event: vdev_id 0 peer_id 2 mac_addr d902298bM ast_hash 5 hw_peer_id 757
> 
> what is d902298bM? are you using Linux? seems %pM is not properly formatted in your
> environment.

Sory. I got a typo while copy-and-paste. Here's the output:

    peer map event: vdev_id 0 peer_id 2 mac_addr c9:21:f0:04:0e:e0 ast_hash 5 hw_peer_id 757


Best regards
Alexander Wilhelm