CVE-2026-43348

{"id": "CVE-2026-43348", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "affected": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "affectedData": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "7bfe3b8ea6e30437e01fcb8e4f56ef6e4d986d0f", "lessThan": "a142ca4b6481e71498712800b20e0c0fcf02843b", "versionType": "git"}, {"status": "affected", "version": "7bfe3b8ea6e30437e01fcb8e4f56ef6e4d986d0f", "lessThan": "404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd", "versionType": "git"}], "programFiles": ["drivers/hv/mshv_vtl_main.c", "include/uapi/linux/mshv.h"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "6.19"}, {"status": "unaffected", "version": "0", "lessThan": "6.19", "versionType": "semver"}, {"status": "unaffected", "version": "7.0.2", "versionType": "semver", "lessThanOrEqual": "7.0.*"}, {"status": "unaffected", "version": "7.1", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["drivers/hv/mshv_vtl_main.c", "include/uapi/linux/mshv.h"], "defaultStatus": "affected"}]}], "published": "2026-05-08T14:16:44.890", "references": [{"url": "https://git.kernel.org/stable/c/404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a142ca4b6481e71498712800b20e0c0fcf02843b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER\n\nWhen registering VTL0 memory via MSHV_ADD_VTL0_MEMORY, the kernel\ncomputes pgmap->vmemmap_shift as the number of trailing zeros in the\nOR of start_pfn and last_pfn, intending to use the largest compound\npage order both endpoints are aligned to.\n\nHowever, this value is not clamped to MAX_FOLIO_ORDER, so a\nsufficiently aligned range (e.g. physical range\n[0x800000000000, 0x800080000000), corresponding to start_pfn=0x800000000\nwith 35 trailing zeros) can produce a shift larger than what\nmemremap_pages() accepts, triggering a WARN and returning -EINVAL:\n\n WARNING: ... memremap_pages+0x512/0x650\n requested folio size unsupported\n\nThe MAX_FOLIO_ORDER check was added by\ncommit 646b67d57589 (\"mm/memremap: reject unreasonable folio/compound\npage sizes in memremap_pages()\").\n\nFix this by clamping vmemmap_shift to MAX_FOLIO_ORDER so we always\nrequest the largest order the kernel supports, in those cases, rather\nthan an out-of-range value.\n\nAlso fix the error path to propagate the actual error code from\ndevm_memremap_pages() instead of hard-coding -EFAULT, which was\nmasking the real -EINVAL return."}, {"lang": "es", "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nmshv_vtl: Soluci\u00f3n para vmemmap_shift excediendo MAX_FOLIO_ORDER\n\nAl registrar memoria VTL0 a trav\u00e9s de MSHV_ADD_VTL0_MEMORY, el kernel calcula pgmap -> vmemmap_shift como el n\u00famero de ceros finales en el OR de start_pfn y last_pfn, con la intenci\u00f3n de usar el orden de p\u00e1gina compuesto m\u00e1s grande al que ambos puntos finales est\u00e1n alineados.\n\nSin embargo, este valor no est\u00e1 limitado a MAX_FOLIO_ORDER, por lo que un rango suficientemente alineado (por ejemplo, rango f\u00edsico [0x 800000000000, 0x 800080000000), correspondiente a start_pfn=0x 800000000 con 35 ceros finales) puede producir un desplazamiento mayor de lo que acepta memremap_pages(), lo que activa una ADVERTENCIA y devuelve -EINVAL:\n\n ADVERTENCIA: ... memremap_pages+0x512/0x650\n tama\u00f1o de folio solicitado no compatible\n\nLa verificaci\u00f3n de MAX_FOLIO_ORDER fue a\u00f1adida por el commit 646b67d57589 (\u2019mm/memremap: rechazar tama\u00f1os de folio/p\u00e1gina compuesta irrazonables en memremap_pages()\u2019).\n\nSolucione esto limitando vmemmap_shift a MAX_FOLIO_ORDER para que siempre solicitemos el orden m\u00e1s grande que el kernel soporta, en esos casos, en lugar de un valor fuera de rango.\n\nTambi\u00e9n corrija la ruta de error para propagar el c\u00f3digo de error real de devm_memremap_pages() en lugar de codificar -EFAULT, lo que estaba enmascarando el retorno real de -EINVAL."}], "lastModified": "2026-11-11T20:10:00.273", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "1BD58F1E-7C20-4C0D-92A2-FAC5CBFBE8A8", "versionEndExcluding": "7.0.2", "versionStartIncluding": "6.19"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}