cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed
In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.261, 5.15.212, 6.1.178, 6.12.97, 6.18.40, 6.6.145, 7.1.5
- CVEs
- CVE-2026-72010
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 07:47 UTC · Revision 1
Source evidence
cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed
core-osv · Original sourcePublished 15 Aug 2026, 05:51 UTC
In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]
osv:CVE-2026-72010
Kernel
Fixed versions: 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5
Complete source record
{
"id": "5237de9698fed05fb18da53dac96d648922dce2f8bcefefe8789dabacf654046",
"url": "https://osv.dev/vulnerability/CVE-2026-72010",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed",
"summary": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]",
"evidence": "osv:CVE-2026-72010",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.261",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.212",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.178",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.145",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.97",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.40",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.5",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-72010",
"aliases": [
"CVE-2026-72010"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "ae1c802382f7af60aa54879fb4f5920a9df1ff48"
},
{
"fixed": "b7adeba2a21c98c7b20f18e27e3ead86bdb5e08d"
},
{
"fixed": "fcc8c310539c3cc523419113b227161a96b50550"
},
{
"fixed": "4b06449384b9ee5b3372bab60601ba5cd4162086"
},
{
"fixed": "02f67c4f88be8e3dbd91951d13cdcc5bcc82e9c7"
},
{
"fixed": "fc680afc510157f6b137956011c09abc23eb0842"
},
{
"fixed": "c844b7d9a9586de15dd28c06da5cc7f6ab28787d"
},
{
"fixed": "c17f06d8a085d6be58b544a440ce243f5e441a60"
},
{
"fixed": "b983c56426383e4a06fa5970c4e33cee879b1482"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72010.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "3.17.0"
},
{
"fixed": "5.10.261"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.212"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.178"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.145"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.97"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.40"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.5"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72010.json"
}
}
],
"modified": "2026-10-28T02:30:26.799537365Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/02f67c4f88be8e3dbd91951d13cdcc5bcc82e9c7",
"https://git.kernel.org/stable/c/4b06449384b9ee5b3372bab60601ba5cd4162086",
"https://git.kernel.org/stable/c/b7adeba2a21c98c7b20f18e27e3ead86bdb5e08d",
"https://git.kernel.org/stable/c/b983c56426383e4a06fa5970c4e33cee879b1482",
"https://git.kernel.org/stable/c/c17f06d8a085d6be58b544a440ce243f5e441a60",
"https://git.kernel.org/stable/c/c844b7d9a9586de15dd28c06da5cc7f6ab28787d",
"https://git.kernel.org/stable/c/fc680afc510157f6b137956011c09abc23eb0842",
"https://git.kernel.org/stable/c/fcc8c310539c3cc523419113b227161a96b50550",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72010.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-72010",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72010.json"
}
},
"related_cves": [
{
"value": "CVE-2026-72010",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 493517,
"published_at": "2026-08-15T05:51:39.755+00:00"
}