Cloudanix VulnDB

CVE-2026-90348

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in certain Linux WiFi drivers can make the whole computer crash when the WiFi hardware has a problem and tries to save diagnostic information.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect use of memcpy on a MEMREMAP_WT device mapping for MSA RAM on arm64 triggers alignment faults in optimized memcpy paths, causing kernel oops, zeroed crash dumps, and failure of modem SSR recovery during ath10k firmware crash handling.

Why it matters to the business

Unexpected kernel crashes occur when WiFi firmware fails, preventing proper recovery and diagnostic collection; urgency is low given absent KEV listing, ransomware use, and flat EPSS trend 37 days after publication.

How an attack unfolds

An attacker with local access or the ability to induce ath10k firmware crashes on affected WCN3990/SNOC hardware can trigger the unaligned access during devcoredump collection, resulting in kernel panic; no named threat actors or campaigns are associated.

How to fix it

Update to a Linux kernel containing the memcpy_fromio() replacement in ath10k_snoc; apply the unconditional change also used by ath11k/ath12k and verify the __force cast for sparse.

How to confirm the fix worked

Confirm the source uses memcpy_fromio() with proper __iomem casting for MSA region; reproduce firmware crash on WCN3990 hardware and verify no alignment fault or kernel panic occurs.

Typical attack path

  1. Gain local execution or network position allowing WiFi firmware crash induction on arm64 SNOC platform
  2. Trigger ath10k firmware crash to invoke ath10k_snoc_fw_crashed_dump
  3. Execute unaligned memcpy against MEMREMAP_WT mapping causing FSC=0x21 alignment fault
  4. Observe kernel oops, zeroed RAM dump, and broken modem recovery

How to detect it

Search kernel logs for alignment fault FSC=0x21 during ath10k_snoc_fw_crashed_dump or __pi_memcpy_generic calls; examine devcoredump paths and modem SSR failure events on affected hardware.

What your security team should do

  • Prioritize kernel updates on arm64 devices using ath10k SNOC/WCN3990 WiFi
  • Monitor for kernel oops during WiFi firmware recovery events
  • Test crash-dump paths in lab environments matching production hardware

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] 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 memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), 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 MEMREMAP_WT 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

Affected packages

Ecosystem Package Introduced Fixed