CVE-2026-43348
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
mshv_vtl: Fix vmemmap_shift overschrijding MAX_FOLIO_ORDER
Bij het registreren van VTL0 geheugen via MSHV_ADD_VTL0_MEMORY, zal de kernel
berekent pgmap->vmemmap_shift als het aantal achterliggende nullen in de
OF van start_pfn en last_pfn, met de intentie om de grootste verbinding te gebruiken
paginavolgorde waarop beide eindpunten zijn uitgelijnd. Deze waarde is echter niet geklemd op MAX_FOLIO_ORDER, dus een
voldoende uitgelijnd bereik (bijv. fysiek bereik
[0x800000000000, 0x800080000000), overeenkomend met start_pfn=0x800000000
met 35 achterliggende nullen) kan een verschuiving produceren die groter is dan wat
memremap_pages() accepteert, activeert een WAARSCHUWING en keert terug -EINVAL:
WAARSCHUWING: ... memremap_pages+0x512/0x650
aangevraagde folio-grootte niet ondersteund
De MAX_FOLIO_ORDER controle is toegevoegd door
commit 646b67d57589 ("mm/memremap: reject unreasonable folio/compound
paginaformaten in memremap_pages()"). Los dit op door vmemmap_shift vast te klemmen op MAX_FOLIO_ORDER zodat we altijd
vraag de grootste bestelling aan die de kernel ondersteunt, in die gevallen
dan een waarde buiten bereik. Bevestig ook het foutpad om de werkelijke foutcode van
devm_memremap_pages() in plaats van hard-coding -EFAULT, dat
het maskeren van de echte -EINVAL return.
Origineel (Engels) tonen
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.