CVE-2026-90348: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: snoc: use memcpyfromio() for MSA ramdump
On WCN3990/SNOC the MSA region is mapped with devmmemremap(MEMREMAPWT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10kmsadumpmemory() copies the region with a plain memcpy(), whose optimized pimemcpygeneric implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10ksnocfwcrasheddump() while collecting the devcoredump:
Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : pimemcpygeneric lr : ath10ksnocfwcrasheddump [ath10ksnoc]
The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery.
Use memcpyfromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpyfromio() implementation aligns the source before issuing word-sized reads and stores the destination with putunaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAPWT pointer is a plain void , so an explicit iomem cast is needed; use force to keep sparse happy.
Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
When copying the MSA region for wifi: ath10k: snoc firmware crash dumps (e.g., in ath10k_snoc_fw_crashed_dump()/ath10k_msa_dump_memory() during devcoredump), use memcpy_fromio() so accesses are valid for the device-memory mapping (MEMREMAP_WT) and avoid alignment faults (FSC=0x21) and kernel Oops.
Linux kernel ath10k (snoc) MSA ramdump Use memcpy_fromio() instead of memcpy()/generic memcpy() for MSA region copies = memcpy_fromio() - Configuration
Apply the same pattern as described for ath10k: use memcpy_fromio() unconditionally when copying target memory into crash dumps for ath11k to avoid word-sized wide/unaligned loads that trigger alignment faults.
Linux kernel ath11k MSA ramdump Use memcpy_fromio() for MSA RAM dump copies = memcpy_fromio() - Configuration
Apply the same pattern as described for ath10k: use memcpy_fromio() unconditionally when copying target memory into crash dumps for ath12k to avoid word-sized wide/unaligned loads that trigger alignment faults.
Linux kernel ath12k MSA ramdump Use memcpy_fromio() for MSA RAM dump copies = memcpy_fromio()
Event History
Frequently Asked Questions
Which systems are exposed to this failure?
The issue is described for WCN3990/SNOC systems on arm64, where the MSA region is mapped with devm_memremap(MEMREMAP_WT). It affects the ath10k SNOC firmware-crash dump path.
When does the problem occur, and how can it be identified?
It occurs while ath10k_snoc_fw_crashed_dump() collects a devcoredump after firmware failure. Affected systems can log an arm64 alignment fault with FSC=0x21, with __pi_memcpy_generic and ath10k_snoc_fw_crashed_dump in the fault stack.
What is the operational impact?
The firmware RAM dump buffer remains zeroed, so no useful dump is captured. The resulting kernel Oops crashes the kernel and breaks modem SSR recovery.
What change resolves the issue?
The resolved implementation uses memcpy_fromio() rather than plain memcpy() when copying the MSA RAM dump. memcpy_fromio() performs accesses valid for the device-memory mapping and is also safe for the coherent DMA allocation path.