Re: [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian
Baochen Qiang <[email protected]>
| Newsgroups | org.infradead.lists.ath12k,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless |
|---|---|
| Message-ID | <[email protected]> |
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