FKIE_CVE-2026-31397
Vulnerability from fkie_nvd - Published: 2026-04-03 16:16 - Updated: 2026-07-24 22:10| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/huge_memory.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f3caaee0f9e489fd2282d4ce45791dc8aed2da62",
"status": "affected",
"version": "e3981db444a0a18d350d9f92e3f2e8d489b54211",
"versionType": "git"
},
{
"lessThan": "e3133d0986dc5a231d5419167dbac65312b28b41",
"status": "affected",
"version": "e3981db444a0a18d350d9f92e3f2e8d489b54211",
"versionType": "git"
},
{
"lessThan": "fae654083bfa409bb2244f390232e2be47f05bfc",
"status": "affected",
"version": "e3981db444a0a18d350d9f92e3f2e8d489b54211",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/huge_memory.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.16"
},
{
"lessThan": "6.16",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.20",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1C570CE1-BC61-4BE6-9393-FD0CA8637367",
"versionEndExcluding": "6.18.20",
"versionStartIncluding": "6.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "96D34333-38BE-4414-9E79-6EB764329581",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*",
"matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*",
"matchCriteriaId": "4AE85AD8-4641-4E7C-A2F4-305E2CD9EE64",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F666C8D8-6538-46D4-B318-87610DE64C34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*",
"matchCriteriaId": "02259FDA-961B-47BC-AE7F-93D7EC6E90C2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix use of NULL folio in move_pages_huge_pmd()\n\nmove_pages_huge_pmd() handles UFFDIO_MOVE for both normal THPs and huge\nzero pages. For the huge zero page path, src_folio is explicitly set to\nNULL, and is used as a sentinel to skip folio operations like lock and\nrmap.\n\nIn the huge zero page branch, src_folio is NULL, so folio_mk_pmd(NULL,\npgprot) passes NULL through folio_pfn() and page_to_pfn(). With\nSPARSEMEM_VMEMMAP this silently produces a bogus PFN, installing a PMD\npointing to non-existent physical memory. On other memory models it is a\nNULL dereference.\n\nUse page_folio(src_page) to obtain the valid huge zero folio from the\npage, which was obtained from pmd_page() and remains valid throughout.\n\nAfter commit d82d09e48219 (\"mm/huge_memory: mark PMD mappings of the huge\nzero folio special\"), moved huge zero PMDs must remain special so\nvm_normal_page_pmd() continues to treat them as special mappings.\n\nmove_pages_huge_pmd() currently reconstructs the destination PMD in the\nhuge zero page branch, which drops PMD state such as pmd_special() on\narchitectures with CONFIG_ARCH_HAS_PTE_SPECIAL. As a result,\nvm_normal_page_pmd() can treat the moved huge zero PMD as a normal page\nand corrupt its refcount.\n\nInstead of reconstructing the PMD from the folio, derive the destination\nentry from src_pmdval after pmdp_huge_clear_flush(), then handle the PMD\nmetadata the same way move_huge_pmd() does for moved entries by marking it\nsoft-dirty and clearing uffd-wp."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nmm/huge_memory: corrige el uso de folio NULL en move_pages_huge_pmd()\n\nmove_pages_huge_pmd() maneja UFFDIO_MOVE tanto para THPs normales como para p\u00e1ginas cero enormes. Para la ruta de la p\u00e1gina cero enorme, src_folio se establece expl\u00edcitamente en NULL, y se usa como un centinela para omitir operaciones de folio como lock y rmap.\n\nEn la rama de la p\u00e1gina cero enorme, src_folio es NULL, por lo que folio_mk_pmd(NULL, pgprot) pasa NULL a trav\u00e9s de folio_pfn() y page_to_pfn(). Con SPARSEMEM_VMEMMAP esto produce silenciosamente un PFN err\u00f3neo, instalando un PMD que apunta a memoria f\u00edsica inexistente. En otros modelos de memoria es una desreferencia NULL.\n\nUsar page_folio(src_page) para obtener el folio cero enorme v\u00e1lido de la p\u00e1gina, que se obtuvo de pmd_page() y permanece v\u00e1lido en todo momento.\n\nDespu\u00e9s del commit d82d09e48219 (\u0027mm/huge_memory: marcar las asignaciones PMD del folio cero enorme como especiales\u0027), los PMD cero enormes movidos deben permanecer especiales para que vm_normal_page_pmd() contin\u00fae trat\u00e1ndolos como asignaciones especiales.\n\nmove_pages_huge_pmd() actualmente reconstruye el PMD de destino en la rama de la p\u00e1gina cero enorme, lo que elimina el estado del PMD como pmd_special() en arquitecturas con CONFIG_ARCH_HAS_PTE_SPECIAL. Como resultado, vm_normal_page_pmd() puede tratar el PMD cero enorme movido como una p\u00e1gina normal y corromper su refcount.\n\nEn lugar de reconstruir el PMD a partir del folio, derivar la entrada de destino de src_pmdval despu\u00e9s de pmdp_huge_clear_flush(), luego manejar los metadatos del PMD de la misma manera que move_huge_pmd() lo hace para las entradas movidas, marc\u00e1ndolo como soft-dirty y borrando uffd-wp."
}
],
"id": "CVE-2026-31397",
"lastModified": "2026-07-24T22:10:00.140",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-04-03T16:16:38.093",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e3133d0986dc5a231d5419167dbac65312b28b41"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f3caaee0f9e489fd2282d4ce45791dc8aed2da62"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fae654083bfa409bb2244f390232e2be47f05bfc"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
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.
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.