{"api_version":"1","generated_at":"2026-10-07T04:38:41+00:00","cve":"CVE-2026-89966","urls":{"html":"https://cve.report/CVE-2026-89966","api":"https://cve.report/api/cve/CVE-2026-89966.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-89966","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-89966"},"summary":{"title":"mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio\n\nalloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to\nalloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes.  If\norder is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL\nnodemask down to hugetlb_cma_alloc_frozen_folio() via\nalloc_gigantic_frozen_folio().\n\nAdditionally, hugetlb_cma_alloc_frozen_folio() previously attempted\nallocation on hugetlb_cma[nid] without verifying if nid is included in the\ncaller's nodemask.  Adding a node_isset(nid, *nodemask) check ensures the\ninitial preferred node allocation honors the memory policy / nodemask.\n\nHowever, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in\nnode_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask),\nleading to a null pointer dereference kernel panic when nodemask is NULL.\n\nFix this by checking if nodemask is NULL in\nhugetlb_cma_alloc_frozen_folio() and defaulting it to\ncpuset_current_mems_allowed.  Enclose the allocation attempts within the\ncpuset seqcount retry loop so that if the cpuset changes concurrently\nduring allocation, the attempts are retried using the updated nodemask. \nThis ensures that the initial node check and fallback loop safely honor\nthe task's cpuset without violating cpuset constraints or causing NULL\npointer dereferences or unexpected allocation failures.\n\nFrom a userspace perspective, this bug allows an unprivileged user to\ncrash the kernel (trigger a panic) by requesting a gigantic hugepage\nallocation with MPOL_PREFERRED_MANY on a system where CMA is only\nconfigured on a subset of NUMA nodes.\n\nThis can be reproduced by booting a VM with two NUMA nodes, restricting\nCMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G\nhugepages=0), and running a program that allocates a 1GB hugepage area\nwithout reserving, restricts allocation to Node 0 using mbind() with\nMPOL_PREFERRED_MANY, and triggers a page fault:\n\n  void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE,\n                   MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB |\n                   MAP_HUGE_1GB | MAP_NORESERVE, -1, 0);\n  unsigned long nodemask = 1; /* Node 0 */\n  mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask,\n        sizeof(nodemask) * 8, 0);\n  memset(ptr, 0, 1UL << 30); /* Trigger fault */\n\nThis results in a NULL pointer dereference:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  Oops: Oops: 0000 [#1] SMP NOPTI\n  RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120\n  Call Trace:\n   <TASK>\n   only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160\n   alloc_surplus_hugetlb_folio+0x6d/0x100\n   alloc_hugetlb_folio+0x3c5/0x660\n   hugetlb_no_page+0x3d9/0x650","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-16 11:17:07","updated_at":"2026-09-16 11:17:07"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/10f616ef06c5bd2d656a0eebaf73f9b09d150c24","name":"https://git.kernel.org/stable/c/10f616ef06c5bd2d656a0eebaf73f9b09d150c24","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/7b8a8ae4dd176a232e973017d2aa3c536a7275e2","name":"https://git.kernel.org/stable/c/7b8a8ae4dd176a232e973017d2aa3c536a7275e2","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89966","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89966","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected eb02f14c4a2bf4c242d91c4a5d7fb57c3c0ad1b1 10f616ef06c5bd2d656a0eebaf73f9b09d150c24 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected eb02f14c4a2bf4c242d91c4a5d7fb57c3c0ad1b1 7b8a8ae4dd176a232e973017d2aa3c536a7275e2 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.19","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19 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-rc2 * 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":["mm/hugetlb_cma.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"10f616ef06c5bd2d656a0eebaf73f9b09d150c24","status":"affected","version":"eb02f14c4a2bf4c242d91c4a5d7fb57c3c0ad1b1","versionType":"git"},{"lessThan":"7b8a8ae4dd176a232e973017d2aa3c536a7275e2","status":"affected","version":"eb02f14c4a2bf4c242d91c4a5d7fb57c3c0ad1b1","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["mm/hugetlb_cma.c"],"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.2.*","status":"unaffected","version":"7.2.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc2","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.5","versionStartIncluding":"6.19","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc2","versionStartIncluding":"6.19","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio\n\nalloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to\nalloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes.  If\norder is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL\nnodemask down to hugetlb_cma_alloc_frozen_folio() via\nalloc_gigantic_frozen_folio().\n\nAdditionally, hugetlb_cma_alloc_frozen_folio() previously attempted\nallocation on hugetlb_cma[nid] without verifying if nid is included in the\ncaller's nodemask.  Adding a node_isset(nid, *nodemask) check ensures the\ninitial preferred node allocation honors the memory policy / nodemask.\n\nHowever, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in\nnode_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask),\nleading to a null pointer dereference kernel panic when nodemask is NULL.\n\nFix this by checking if nodemask is NULL in\nhugetlb_cma_alloc_frozen_folio() and defaulting it to\ncpuset_current_mems_allowed.  Enclose the allocation attempts within the\ncpuset seqcount retry loop so that if the cpuset changes concurrently\nduring allocation, the attempts are retried using the updated nodemask. \nThis ensures that the initial node check and fallback loop safely honor\nthe task's cpuset without violating cpuset constraints or causing NULL\npointer dereferences or unexpected allocation failures.\n\nFrom a userspace perspective, this bug allows an unprivileged user to\ncrash the kernel (trigger a panic) by requesting a gigantic hugepage\nallocation with MPOL_PREFERRED_MANY on a system where CMA is only\nconfigured on a subset of NUMA nodes.\n\nThis can be reproduced by booting a VM with two NUMA nodes, restricting\nCMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G\nhugepages=0), and running a program that allocates a 1GB hugepage area\nwithout reserving, restricts allocation to Node 0 using mbind() with\nMPOL_PREFERRED_MANY, and triggers a page fault:\n\n  void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE,\n                   MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB |\n                   MAP_HUGE_1GB | MAP_NORESERVE, -1, 0);\n  unsigned long nodemask = 1; /* Node 0 */\n  mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask,\n        sizeof(nodemask) * 8, 0);\n  memset(ptr, 0, 1UL << 30); /* Trigger fault */\n\nThis results in a NULL pointer dereference:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  Oops: Oops: 0000 [#1] SMP NOPTI\n  RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120\n  Call Trace:\n   <TASK>\n   only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160\n   alloc_surplus_hugetlb_folio+0x6d/0x100\n   alloc_hugetlb_folio+0x3c5/0x660\n   hugetlb_no_page+0x3d9/0x650"}],"providerMetadata":{"dateUpdated":"2026-09-16T10:32:47.482Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/10f616ef06c5bd2d656a0eebaf73f9b09d150c24"},{"url":"https://git.kernel.org/stable/c/7b8a8ae4dd176a232e973017d2aa3c536a7275e2"}],"title":"mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-89966","datePublished":"2026-09-16T10:32:47.482Z","dateReserved":"2026-09-11T19:38:34.778Z","dateUpdated":"2026-09-16T10:32:47.482Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-16 11:17:07","lastModifiedDate":"2026-09-16 11:17:07","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"89966","Ordinal":"1","Title":"mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_all","CVE":"CVE-2026-89966","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"89966","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_alloc_frozen_folio\n\nalloc_buddy_hugetlb_folio_with_mpol() can pass a NULL nodemask to\nalloc_fresh_hugetlb_folio() as a fallback to allocate from all nodes.  If\norder is gigantic, alloc_fresh_hugetlb_folio() propagates the NULL\nnodemask down to hugetlb_cma_alloc_frozen_folio() via\nalloc_gigantic_frozen_folio().\n\nAdditionally, hugetlb_cma_alloc_frozen_folio() previously attempted\nallocation on hugetlb_cma[nid] without verifying if nid is included in the\ncaller's nodemask.  Adding a node_isset(nid, *nodemask) check ensures the\ninitial preferred node allocation honors the memory policy / nodemask.\n\nHowever, hugetlb_cma_alloc_frozen_folio() dereferences the nodemask in\nnode_isset(nid, *nodemask) and for_each_node_mask(node, *nodemask),\nleading to a null pointer dereference kernel panic when nodemask is NULL.\n\nFix this by checking if nodemask is NULL in\nhugetlb_cma_alloc_frozen_folio() and defaulting it to\ncpuset_current_mems_allowed.  Enclose the allocation attempts within the\ncpuset seqcount retry loop so that if the cpuset changes concurrently\nduring allocation, the attempts are retried using the updated nodemask. \nThis ensures that the initial node check and fallback loop safely honor\nthe task's cpuset without violating cpuset constraints or causing NULL\npointer dereferences or unexpected allocation failures.\n\nFrom a userspace perspective, this bug allows an unprivileged user to\ncrash the kernel (trigger a panic) by requesting a gigantic hugepage\nallocation with MPOL_PREFERRED_MANY on a system where CMA is only\nconfigured on a subset of NUMA nodes.\n\nThis can be reproduced by booting a VM with two NUMA nodes, restricting\nCMA to Node 1 (e.g., hugetlb_cma=1:1G default_hugepagesz=1G hugepagesz=1G\nhugepages=0), and running a program that allocates a 1GB hugepage area\nwithout reserving, restricts allocation to Node 0 using mbind() with\nMPOL_PREFERRED_MANY, and triggers a page fault:\n\n  void *ptr = mmap(NULL, 1UL << 30, PROT_READ | PROT_WRITE,\n                   MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB |\n                   MAP_HUGE_1GB | MAP_NORESERVE, -1, 0);\n  unsigned long nodemask = 1; /* Node 0 */\n  mbind(ptr, 1UL << 30, MPOL_PREFERRED_MANY, &nodemask,\n        sizeof(nodemask) * 8, 0);\n  memset(ptr, 0, 1UL << 30); /* Trigger fault */\n\nThis results in a NULL pointer dereference:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  Oops: Oops: 0000 [#1] SMP NOPTI\n  RIP: 0010:hugetlb_cma_alloc_frozen_folio+0x75/0x120\n  Call Trace:\n   <TASK>\n   only_alloc_fresh_hugetlb_folio.isra.0+0x2c/0x160\n   alloc_surplus_hugetlb_folio+0x6d/0x100\n   alloc_hugetlb_folio+0x3c5/0x660\n   hugetlb_no_page+0x3d9/0x650","Type":"Description","Title":"mm/hugetlb_cma: fix null nodemask dereference in hugetlb_cma_all"}]}}}