CVE-2026-43348 Details
Description
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.
A vulnerability in the Linux kernel's mshv_vtl driver can lead to improper memory handling when registering VTL0 memory. The issue arises because the kernel calculates the vmemmap_shift parameter based on the number of trailing zeros in the physical range's page frame numbers (PFNs). This calculation aims to align with the largest compound page order. However, the shift value is not restricted to the maximum allowed folio order, allowing certain aligned ranges to generate a shift that exceeds what the memremap_pages function can handle. This discrepancy triggers a warning and an error, indicating an unsupported folio size. The vulnerability has been addressed by clamping the vmemmap_shift to the maximum folio order, ensuring that only valid page sizes are requested. Additionally, the error handling has been improved to accurately reflect the actual error codes from the memory remapping function, rather than using a generic fault code that obscured the real issue.
The vulnerability has been fixed in the Linux kernel. Users should upgrade to the latest version where this issue has been addressed.
Metrics
CVSS 4.0 Severity and Vector Strings:
No CVSS 4.0 data is available for this CVE.
CVSS 3.x Severity and Vector Strings:
No data available for CVSS Version 2.0 on this CVE.
No SSVC data is available for this CVE.
References to Advisories, Solutions, and Tools
By selecting these links, you will be leaving this site. These are references gathered from the official CVE record and are not endorsed by Volerion.
| URL | Source(s) | Tag(s) |
|---|---|---|
| https://git.kernel.org/stable/c/404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd | kernel.org | Patch |
| https://git.kernel.org/stable/c/a142ca4b6481e71498712800b20e0c0fcf02843b | kernel.org | Patch |
Weakness Enumeration
| CWE-ID | CWE Name | Source |
|---|---|---|
| NVD-CWE-noinfo | Insufficient Information to Classify Weakness | [email protected] |
Affected Products
| Product | Versions |
|---|---|
| linux linux kernel | >= 6.19, < 7.0.2 |
CPE
Remediation
| |
Change History
3 change records found show changes
| Date | Action | Recorded By |
|---|---|---|
| Jun 17, 2026 | CVE Modified | kernel.org |
| May 15, 2026 | Initial Analysis | [email protected] |
| May 8, 2026 | New CVE Received | kernel.org |