{"api_version":"1","generated_at":"2026-10-02T00:11:53+00:00","cve":"CVE-2026-89961","urls":{"html":"https://cve.report/CVE-2026-89961","api":"https://cve.report/api/cve/CVE-2026-89961.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-89961","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-89961"},"summary":{"title":"powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population","description":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population\n\nvmemmap_populate_compound_pages() uses addr_pfn to determine the PFN\noffset within a compound page and to decide whether the current vmemmap\nslot should be populated as a head page mapping or should reuse a tail\npage mapping.\n\nHowever, addr_pfn is advanced manually in parallel with addr.  The loop\nitself progresses in vmemmap address space, so each PAGE_SIZE step in addr\ncovers PAGE_SIZE / sizeof(struct page) struct page slots.  Since addr_pfn\nis compared against nr_pages in data-PFN units, it should advance by the\nsame number of PFNs.  The existing manual increments do not match that and\ntherefore do not reliably track the PFN corresponding to the current addr.\n\nAs a result, pfn_offset can be computed from the wrong PFN and the code\ncan make the head/tail decision for the wrong compound-page position.\n\nFix this by deriving addr_pfn directly from the current vmemmap address\ninstead of carrying it as loop state.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-16 11:17:06","updated_at":"2026-09-16 15:18:20"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/b96be860673f9fbbf12cdadb0b25fc4d6d4d207f","name":"https://git.kernel.org/stable/c/b96be860673f9fbbf12cdadb0b25fc4d6d4d207f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/89a4ae32764172468dea303eb6ae90fe6c859712","name":"https://git.kernel.org/stable/c/89a4ae32764172468dea303eb6ae90fe6c859712","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/9c914b7a0bd18834505c65f22225ce22c152b2d9","name":"https://git.kernel.org/stable/c/9c914b7a0bd18834505c65f22225ce22c152b2d9","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/e163c7184acf36ac20a248498f4a16016057ca01","name":"https://git.kernel.org/stable/c/e163c7184acf36ac20a248498f4a16016057ca01","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/7968852a7ca3ce81477ec5b4494a28d612f35a97","name":"https://git.kernel.org/stable/c/7968852a7ca3ce81477ec5b4494a28d612f35a97","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89961","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89961","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected f2b79c0d79683d552369bb9a7282c1f0226fc566 b96be860673f9fbbf12cdadb0b25fc4d6d4d207f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected f2b79c0d79683d552369bb9a7282c1f0226fc566 e163c7184acf36ac20a248498f4a16016057ca01 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected f2b79c0d79683d552369bb9a7282c1f0226fc566 9c914b7a0bd18834505c65f22225ce22c152b2d9 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected f2b79c0d79683d552369bb9a7282c1f0226fc566 7968852a7ca3ce81477ec5b4494a28d612f35a97 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected f2b79c0d79683d552369bb9a7282c1f0226fc566 89a4ae32764172468dea303eb6ae90fe6c859712 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.6","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.157 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.110 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.51 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.5 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["arch/powerpc/mm/book3s64/radix_pgtable.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"b96be860673f9fbbf12cdadb0b25fc4d6d4d207f","status":"affected","version":"f2b79c0d79683d552369bb9a7282c1f0226fc566","versionType":"git"},{"lessThan":"e163c7184acf36ac20a248498f4a16016057ca01","status":"affected","version":"f2b79c0d79683d552369bb9a7282c1f0226fc566","versionType":"git"},{"lessThan":"9c914b7a0bd18834505c65f22225ce22c152b2d9","status":"affected","version":"f2b79c0d79683d552369bb9a7282c1f0226fc566","versionType":"git"},{"lessThan":"7968852a7ca3ce81477ec5b4494a28d612f35a97","status":"affected","version":"f2b79c0d79683d552369bb9a7282c1f0226fc566","versionType":"git"},{"lessThan":"89a4ae32764172468dea303eb6ae90fe6c859712","status":"affected","version":"f2b79c0d79683d552369bb9a7282c1f0226fc566","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["arch/powerpc/mm/book3s64/radix_pgtable.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.6"},{"lessThan":"6.6","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.157","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.110","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.51","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.157","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.110","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.51","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.5","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"6.6","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population\n\nvmemmap_populate_compound_pages() uses addr_pfn to determine the PFN\noffset within a compound page and to decide whether the current vmemmap\nslot should be populated as a head page mapping or should reuse a tail\npage mapping.\n\nHowever, addr_pfn is advanced manually in parallel with addr.  The loop\nitself progresses in vmemmap address space, so each PAGE_SIZE step in addr\ncovers PAGE_SIZE / sizeof(struct page) struct page slots.  Since addr_pfn\nis compared against nr_pages in data-PFN units, it should advance by the\nsame number of PFNs.  The existing manual increments do not match that and\ntherefore do not reliably track the PFN corresponding to the current addr.\n\nAs a result, pfn_offset can be computed from the wrong PFN and the code\ncan make the head/tail decision for the wrong compound-page position.\n\nFix this by deriving addr_pfn directly from the current vmemmap address\ninstead of carrying it as loop state."}],"metrics":[{"cvssV3_1":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:L - The bug is in powerpc radix vmemmap_populate_compound_pages(), reached only through local ZONE_DEVICE hotplug (dev_dax_probe → devm_memremap_pages → arch_add_memory → sparse_add_section). It is not reachable from network protocols, Bluetooth, or USB.\nAC:L - Once device-DAX with compound vmemmap is mapped (2MB PMD on 4K kernels or 1GB PUD on 64K, the documented powerpc DAX configs), addr_pfn drifts on every loop iteration and the wrong head/tail mapping is deterministic; no race or attacker-uncontrollable layout is required.\nPR:L - Initial memremap requires administrator DAX setup, but on a provisioned persistent-memory or cloud POWER server an unprivileged local user with /dev/dax access can mmap the device and drive kernel use of the mis-aliased struct pages via faults and GUP without init-namespace CAP_SYS_ADMIN.\nUI:N - Exploitation needs no victim action; the attacker mmaps or faults the already-provisioned DAX device themselves. No mount, click, or hotplug by another user is required at exploit time.\nS:U - Impact is kernel struct-page aliasing and MM corruption inside the same host kernel security authority. It is not a KVM guest-to-host escape, IOMMU/DMA bypass, or sandbox boundary crossing.\nC:H - Wrong pfn_offset aliases distinct vmemmap pages so different DAX PFNs share struct-page backing; later memmap_init, faults, and GUP read corrupted flags, mapping, and compound-head fields, disclosing kernel memory via that metadata.\nI:H - The same aliases turn kernel writes (page init, folio mapping, refcount, compound head/tail linkage) into writes to the wrong struct pages, an exploitable kernel memory-corruption primitive that can hijack control flow rather than a bounded data modification.\nA:H - Mis-linked compound pages and aliased vmemmap cause kernel oops, BUG_ON, or panic when MM code walks folio heads, refcounts, or DAX fault handlers, fully denying availability of the affected POWER radix host."}]}],"providerMetadata":{"dateUpdated":"2026-09-16T14:40:41.979Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/b96be860673f9fbbf12cdadb0b25fc4d6d4d207f"},{"url":"https://git.kernel.org/stable/c/e163c7184acf36ac20a248498f4a16016057ca01"},{"url":"https://git.kernel.org/stable/c/9c914b7a0bd18834505c65f22225ce22c152b2d9"},{"url":"https://git.kernel.org/stable/c/7968852a7ca3ce81477ec5b4494a28d612f35a97"},{"url":"https://git.kernel.org/stable/c/89a4ae32764172468dea303eb6ae90fe6c859712"}],"title":"powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-89961","datePublished":"2026-09-16T10:32:43.921Z","dateReserved":"2026-09-11T19:38:34.778Z","dateUpdated":"2026-09-16T14:40:41.979Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-16 11:17:06","lastModifiedDate":"2026-09-16 15:18:20","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"89961","Ordinal":"1","Title":"powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap popu","CVE":"CVE-2026-89961","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"89961","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population\n\nvmemmap_populate_compound_pages() uses addr_pfn to determine the PFN\noffset within a compound page and to decide whether the current vmemmap\nslot should be populated as a head page mapping or should reuse a tail\npage mapping.\n\nHowever, addr_pfn is advanced manually in parallel with addr.  The loop\nitself progresses in vmemmap address space, so each PAGE_SIZE step in addr\ncovers PAGE_SIZE / sizeof(struct page) struct page slots.  Since addr_pfn\nis compared against nr_pages in data-PFN units, it should advance by the\nsame number of PFNs.  The existing manual increments do not match that and\ntherefore do not reliably track the PFN corresponding to the current addr.\n\nAs a result, pfn_offset can be computed from the wrong PFN and the code\ncan make the head/tail decision for the wrong compound-page position.\n\nFix this by deriving addr_pfn directly from the current vmemmap address\ninstead of carrying it as loop state.","Type":"Description","Title":"powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap popu"}]}}}