CVE-2026-43348: Linux Kernel Memory Mapping Vulnerability

CVE-2026-43348 Overview

CVE-2026-43348 is a Linux kernel vulnerability in the mshv_vtl driver, which handles Microsoft Hypervisor Virtual Trust Level (VTL) memory registration. The flaw resides in the MSHV_ADD_VTL0_MEMORY ioctl path, where the kernel computes pgmap->vmemmap_shift without clamping the result to MAX_FOLIO_ORDER. A sufficiently aligned physical memory range causes memremap_pages() to reject the request, triggering a kernel WARN and returning -EINVAL. The issue affects local users with privileges to invoke the relevant ioctl on hypervisor-enabled systems.

Critical Impact

A local privileged user can trigger a kernel warning and prevent VTL0 memory registration, resulting in denial of service for hypervisor-backed workloads.

Affected Products

• Linux Kernel (upstream mshv_vtl driver)
• Distributions shipping kernels with the Microsoft Hypervisor VTL subsystem enabled
• Systems supporting MSHV_ADD_VTL0_MEMORY ioctl

Discovery Timeline

• 2026-05-08 - CVE-2026-43348 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43348

Vulnerability Analysis

The mshv_vtl driver registers VTL0 memory ranges on behalf of user space through the MSHV_ADD_VTL0_MEMORY interface. During registration, the kernel computes pgmap->vmemmap_shift as the number of trailing zeros in the bitwise OR of start_pfn and last_pfn. The intent is to select the largest compound page order to which both endpoints are aligned.

The computed shift is never bounded by MAX_FOLIO_ORDER. When a caller registers a heavily aligned range such as [0x800000000000, 0x800080000000), the computation yields 35 trailing zeros from start_pfn=0x800000000. That shift exceeds the maximum folio order accepted by memremap_pages(), producing the kernel warning requested folio size unsupported and an -EINVAL return.

A secondary defect compounds the impact. The error path hard-codes -EFAULT instead of propagating the actual return value from devm_memremap_pages(), masking the underlying -EINVAL condition and complicating diagnosis.

Root Cause

The root cause is missing input bounds enforcement on a computed page order. The folio order check enforced by commit 646b67d57589 ("mm/memremap: reject unreasonable folio/compound page sizes in memremap_pages()") rejects any shift exceeding MAX_FOLIO_ORDER, but mshv_vtl does not clamp its computed value before calling into the memory remap path.

Attack Vector

Exploitation requires local access and the privileges needed to invoke MSHV_ADD_VTL0_MEMORY on a system exposing the mshv_vtl interface. A local actor submits an aligned PFN range that produces a vmemmap_shift greater than MAX_FOLIO_ORDER. The kernel emits a warning and refuses the registration, disrupting VTL0 memory provisioning and any dependent virtualization workflows.

The upstream fix clamps vmemmap_shift to MAX_FOLIO_ORDER and propagates the real error code from devm_memremap_pages(). See the commits at Kernel Git Commit 404cd6b and Kernel Git Commit a142ca4b for the patch details.

Detection Methods for CVE-2026-43348

Indicators of Compromise

• Kernel log entries containing the string requested folio size unsupported originating from memremap_pages.
• WARNING traces referencing memremap_pages+0x512/0x650 in dmesg output.
• Failed MSHV_ADD_VTL0_MEMORY ioctl calls returning -EFAULT or -EINVAL on hypervisor hosts.

Detection Strategies

• Monitor kernel ring buffer and syslog for memremap_pages warnings tied to the mshv_vtl subsystem.
• Audit processes invoking ioctl against /dev/mshv* device nodes and correlate with subsequent kernel warnings.
• Track running kernel build versions against the stable trees that include the fix commits.

Monitoring Recommendations

• Forward dmesg and journald kernel facility events to a centralized logging pipeline for alerting on WARN traces.
• Establish baselines for legitimate VTL0 memory registration patterns and alert on unexpected callers or alignment anomalies.
• Inventory hosts where the mshv_vtl module is loaded and prioritize them for patch rollout tracking.

How to Mitigate CVE-2026-43348

Immediate Actions Required

• Apply the upstream Linux kernel patches that clamp vmemmap_shift to MAX_FOLIO_ORDER in the mshv_vtl driver.
• Restrict access to mshv_vtl device nodes to trusted administrative accounts and service identities.
• Audit which workloads invoke MSHV_ADD_VTL0_MEMORY and validate the PFN ranges they submit.

Patch Information

The fix is available in the stable Linux kernel trees via commits 404cd6b and a142ca4b. The patches clamp the computed vmemmap_shift to MAX_FOLIO_ORDER and propagate the actual return code from devm_memremap_pages() rather than masking it with -EFAULT.

Workarounds

• Limit the file mode and ownership on mshv_vtl device nodes so only required service accounts can issue the ioctl.
• Avoid registering VTL0 memory ranges whose start_pfn and last_pfn share trailing zero counts greater than MAX_FOLIO_ORDER.
• Where feasible, unload the mshv_vtl module on hosts that do not require Microsoft Hypervisor VTL functionality until patches are deployed.

# Configuration example: restrict access and inventory affected hosts
ls -l /dev/mshv* 2>/dev/null
chmod 0600 /dev/mshv_vtl 2>/dev/null
lsmod | grep -i mshv
dmesg | grep -E 'memremap_pages|requested folio size unsupported'