CVE-2026-43347
Memory Corruption in Linux Kernel on Qualcomm Monaco Platform
Publication date: 2026-05-08
Last updated on: 2026-05-08
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| qualcomm | linux_kernel | * |
| qualcomm | linux_kernel | From 2025-11-17 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in the Linux kernel on Monaco-based platforms using the arm64 architecture. The kernel mistakenly accesses memory owned by the Qualcomm hypervisor, which is not properly marked as reserved in the EFI memory map. Specifically, a portion of the Gunyah hypervisor metadata region is incorrectly reported as conventional memory, leading the kernel's memory allocator to assign physical frames within this hypervisor-owned area.
As a result, when the kernel accesses these addresses, it triggers spurious "Synchronous External Abort" exceptions and causes kernel crashes. The fix involves reserving the full Gunyah metadata region and marking it as no-map so that Linux neither maps nor allocates memory from this sensitive area.
How can this vulnerability impact me? :
This vulnerability can cause unexpected kernel crashes and system instability on affected Monaco-based platforms. The kernel's inadvertent access to hypervisor-owned memory leads to fatal aborts, which can disrupt normal system operations and potentially cause data loss or service interruptions.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing spurious "Synchronous External Abort" exceptions (ESR=0x96000010) and kernel crashes on Monaco-based platforms.
From the boot log, you can check for messages indicating that the Qualcomm hypervisor reports a memory range at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned, but the EFI memory map only reserves a subrange, leaving part of the hypervisor-owned memory incorrectly reported as conventional memory.
Commands to inspect the EFI memory map and kernel logs may help detect this issue, such as checking dmesg or journalctl for related abort exceptions and memory reservation messages.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is mitigated by adding a reserved-memory carveout for the Gunyah hypervisor metadata at 0x91a80000 (512 KiB) and marking it as no-map so that Linux does not map or allocate from this area.
This prevents the kernel from inadvertently accessing hypervisor-owned memory that is not properly marked as reserved, thus avoiding the fatal aborts and kernel crashes.