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

Alexander Wilhelm alexander.wilhelm at westermo.com
Thu Jul 2 05:06:42 PDT 2026


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



More information about the ath12k mailing list