CVE-2026-90348 Affecting kernel-livepatch-6_4_0-150700_53_90-default package, versions <1-150700.15.3.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES157-KERNELLIVEPATCH6401507005390DEFAULT-22238846
- published5 Nov 2026
- disclosed3 Nov 2026
Introduced: 3 Nov 2026
NewCVE-2026-90348 (opens in a new tab)How to fix?
Upgrade SLES:15.7 kernel-livepatch-6_4_0-150700_53_90-default to version 1-150700.15.3.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6_4_0-150700_53_90-default package and not the kernel-livepatch-6_4_0-150700_53_90-default package as distributed by SLES.
See How to fix? for SLES:15.7 relevant fixed versions and status.
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
References
- https://www.suse.com/security/cve/CVE-2026-90348.html
- https://bugzilla.suse.com/1281886
- https://git.kernel.org/stable/c/045d1bfb72d2631ab9ec74afa491aa788ebb57aa
- https://git.kernel.org/stable/c/152e894e90716163c646d70f86b3afeb70442783
- https://git.kernel.org/stable/c/4f25071afe9218aaae1c63fbf75e229aa6405319
- https://git.kernel.org/stable/c/7039825a7479df637c4f5d546cb0e1cec18cd8e1
- https://git.kernel.org/stable/c/838cab267ce9a975776e022f25094f8cbe1625d2
- https://git.kernel.org/stable/c/e5bc3658da9c8a535e3fa5c0c875b2a456954e81
- https://git.kernel.org/stable/c/eb946595a58decdb4cab1b5f3c972ae66f41f1c8
- https://git.kernel.org/stable/c/fed1f662c9f9fd19eeab6c01966b7b5a33804420