CVE-2026-43348

In the Linux kernel, the following vulnerability has been resolved:

mshvvtl: Fix vmemmapshift exceeding MAXFOLIOORDER

When registering VTL0 memory via MSHVADDVTL0MEMORY, the kernel computes pgmap->vmemmapshift as the number of trailing zeros in the OR of startpfn and lastpfn, intending to use the largest compound page order both endpoints are aligned to.

However, this value is not clamped to MAXFOLIOORDER, so a sufficiently aligned range (e.g. physical range [0x800000000000, 0x800080000000), corresponding to startpfn=0x800000000 with 35 trailing zeros) can produce a shift larger than what memremappages() accepts, triggering a WARN and returning -EINVAL:

WARNING: ... memremap_pages+0x512/0x650 requested folio size unsupported

The MAXFOLIOORDER check was added by commit 646b67d57589 ("mm/memremap: reject unreasonable folio/compound page sizes in memremap_pages()").

Fix this by clamping vmemmapshift to MAXFOLIO_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 devmmemremappages() instead of hard-coding -EFAULT, which was masking the real -EINVAL return.