LiveActive security incident?Get immediate response
CVE Record

CVE-2026-43348: mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

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.
Prepared
Confidence
medium
Sources
4

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux7bfe3b8ea6e30437e01fcb8e4f56ef6e4d986d0f, 7bfe3b8ea6e30437e01fcb8e4f56ef6e4d986d0funaffected
LinuxLinux6.19, 0, 7.0.2, 7.1affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.