In the Linux kernel, the following vulnerability has been resolved:
mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER
When registering VTL0 memory via MSHV_ADD_VTL0_MEMORY, the kernel
computes pgmap->vmemmap_shift as the number of trailing zeros in the
OR of start_pfn and last_pfn, intending to use the largest compound
page order both endpoints are aligned to.
However, this value is not clamped to MAX_FOLIO_ORDER, so a
sufficiently aligned range (e.g. physical range
[0x800000000000, 0x800080000000), corresponding to start_pfn=0x800000000
with 35 trailing zeros) can produce a shift larger than what
memremap_pages() accepts, triggering a WARN and returning -EINVAL:
WARNING: ... memremap_pages+0x512/0x650
requested folio size unsupported
The MAX_FOLIO_ORDER check was added by
commit 646b67d57589 ("mm/memremap: reject unreasonable folio/compound
page sizes in memremap_pages()").
Fix this by clamping vmemmap_shift to MAX_FOLIO_ORDER so we always
request the largest order the kernel supports, in those cases, rather
than an out-of-range value.
Also fix the error path to propagate the actual error code from
devm_memremap_pages() instead of hard-coding -EFAULT, which was
masking the real -EINVAL return.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue affects a specialized memory-registration path. A too-large calculated page order can make the kernel reject the request and log a warning. The public record does not show code execution, privilege escalation, or active exploitation. Business urgency is mainly for environments using the affected kernel feature.
Executive priority
Schedule remediation through the normal kernel patch cycle, with higher priority for systems relying on this VTL0 memory-registration path. There is no cited evidence of active exploitation or broad remote exposure, but affected systems may experience feature failure under specific conditions.
Technical view
In mshv_vtl, MSHV_ADD_VTL0_MEMORY computes pgmap->vmemmap_shift from aligned PFN endpoints without clamping it to MAX_FOLIO_ORDER. memremap_pages() rejects unsupported folio sizes, warns, and returns -EINVAL. The fix clamps vmemmap_shift and preserves the real devm_memremap_pages() error code.
Likely exposure
Exposure appears limited to affected Linux kernel versions containing the mshv_vtl path and systems exercising MSHV_ADD_VTL0_MEMORY for VTL0 memory registration. The source bundle lists Linux versions 6.19, 7.0.2, and 7.1 as affected, but distribution packaging status is not provided.
Exploitation context
No source indicates active exploitation, and KEV is false. The described impact is a failed memory registration with a kernel warning under sufficiently aligned physical memory ranges. Practical exploitability and security impact beyond availability or feature failure are not established in the provided sources.
Researcher notes
The root cause is an unchecked vmemmap_shift derived from PFN alignment exceeding MAX_FOLIO_ORDER after memremap_pages() added stricter validation. The patch clamps the value and fixes masked error reporting. Severity, CVSS, CWE, and detailed impact are not provided in the source bundle.
Mitigation direction
Apply a Linux kernel update containing the referenced stable fixes.
Check your Linux distribution or kernel vendor advisory for packaged fixes.
Prioritize systems using mshv_vtl or VTL0 memory registration paths.
If patching is delayed, monitor vendor guidance for supported workarounds.
Validation and detection
Inventory running kernel versions against vendor fixed builds.
Confirm whether the referenced stable commits are included in your kernel tree.
Identify systems using mshv_vtl or MSHV_ADD_VTL0_MEMORY functionality.
Review kernel logs for memremap_pages warnings about unsupported folio size.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43348 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 8, 2026, 13:41 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.