FKIE_CVE-2026-43348
Vulnerability from fkie_nvd - Published: 2026-05-08 14:16 - Updated: 2026-06-17 10:49
Severity
Summary
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.
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/hv/mshv_vtl_main.c",
"include/uapi/linux/mshv.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a142ca4b6481e71498712800b20e0c0fcf02843b",
"status": "affected",
"version": "7bfe3b8ea6e30437e01fcb8e4f56ef6e4d986d0f",
"versionType": "git"
},
{
"lessThan": "404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd",
"status": "affected",
"version": "7bfe3b8ea6e30437e01fcb8e4f56ef6e4d986d0f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/hv/mshv_vtl_main.c",
"include/uapi/linux/mshv.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.19"
},
{
"lessThan": "6.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.1",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1BD58F1E-7C20-4C0D-92A2-FAC5CBFBE8A8",
"versionEndExcluding": "7.0.2",
"versionStartIncluding": "6.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"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-\u003evmemmap_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."
}
],
"id": "CVE-2026-43348",
"lastModified": "2026-06-17T10:49:25.813",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2026-05-08T14:16:44.890",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a142ca4b6481e71498712800b20e0c0fcf02843b"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…