Skip to main content

Linux Kernel CVE-2026-43348

| EUVDEUVD-2026-28632 MEDIUM
2026-05-08 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-j2m4-498q-2w8w
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 15, 2026 - 19:39 vuln.today
CVSS changed
May 15, 2026 - 19:37 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 15:17 EUVD
CVE Published
May 08, 2026 - 14:16 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

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.

AnalysisAI

The Linux kernel mshv_vtl driver permits local denial-of-service via memory registration failure when VTL0 memory ranges are sufficiently aligned (35+ trailing zeros in physical address). An unclamped vmemmap_shift calculation can exceed MAX_FOLIO_ORDER, causing memremap_pages() to reject the operation and potentially destabilize virtualization infrastructure. CVSS 5.5 indicates local authenticated exploitation with low complexity. EPSS 0.02% suggests minimal real-world targeting. Vendor patches available for kernel 7.0.2 and 7.1-rc1 address both the shift clamping and error propagation issues.

Technical ContextAI

The vulnerability exists in the Microsoft Hypervisor (MSHV) VTL (Virtual Trust Level) driver's memory registration path. When adding VTL0 memory via MSHV_ADD_VTL0_MEMORY ioctl, the driver computes pgmap->vmemmap_shift by counting trailing zeros in the bitwise OR of start_pfn and last_pfn to determine optimal compound page alignment. The code fails to validate this calculated shift against MAX_FOLIO_ORDER (introduced in commit 646b67d57589) before passing to memremap_pages(). Physical memory ranges with extreme alignment (e.g., 0x800000000000 with 35 trailing zeros) produce shift values exceeding kernel limits, triggering validation failures in the memory remapping subsystem. The issue combines integer overflow semantics with kernel memory management constraints, specifically the folio allocation limits enforced since the MAX_FOLIO_ORDER safeguard was added to memremap_pages().

RemediationAI

Upgrade to Linux kernel 7.0.2, 7.1-rc1, or later stable releases containing commits a142ca4b6481e and 404cd6bffe17e which clamp vmemmap_shift to MAX_FOLIO_ORDER and fix error propagation from devm_memremap_pages(). Patches backported to stable branches per kernel.org references. For environments unable to upgrade immediately, disable CONFIG_MSHV_VTL at kernel compile time if VTL memory isolation is not operationally required, eliminating the vulnerable code path entirely. Alternatively, restrict access to /dev/mshv devices using LSM policies or device cgroup controls to limit exploitation surface to trusted virtualization management processes only. Note that disabling CONFIG_MSHV_VTL will break Microsoft Hypervisor VTL functionality for Azure Stack HCI and similar deployments, requiring operational validation before implementing this mitigation. No userspace-only workaround exists as the flaw resides in kernel memory management internals.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

Share

CVE-2026-43348 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy