From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-72010: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed
Date: Sat, 15 Aug 2026 15:01:29 +0900 [thread overview]
Message-ID: <2026081508-CVE-2026-72010-0203@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
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 ]
The Linux kernel CVE team has assigned CVE-2026-72010 to this issue.
Affected and fixed versions
===========================
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 5.10.261 with commit b7adeba2a21c98c7b20f18e27e3ead86bdb5e08d
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 5.15.212 with commit fcc8c310539c3cc523419113b227161a96b50550
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 6.1.178 with commit 4b06449384b9ee5b3372bab60601ba5cd4162086
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 6.6.145 with commit 02f67c4f88be8e3dbd91951d13cdcc5bcc82e9c7
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 6.12.97 with commit fc680afc510157f6b137956011c09abc23eb0842
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 6.18.40 with commit c844b7d9a9586de15dd28c06da5cc7f6ab28787d
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 7.1.5 with commit c17f06d8a085d6be58b544a440ce243f5e441a60
Issue introduced in 3.17 with commit ae1c802382f7af60aa54879fb4f5920a9df1ff48 and fixed in 7.2-rc4 with commit b983c56426383e4a06fa5970c4e33cee879b1482
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-72010
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
kernel/cgroup/cpuset.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/b7adeba2a21c98c7b20f18e27e3ead86bdb5e08d
https://git.kernel.org/stable/c/fcc8c310539c3cc523419113b227161a96b50550
https://git.kernel.org/stable/c/4b06449384b9ee5b3372bab60601ba5cd4162086
https://git.kernel.org/stable/c/02f67c4f88be8e3dbd91951d13cdcc5bcc82e9c7
https://git.kernel.org/stable/c/fc680afc510157f6b137956011c09abc23eb0842
https://git.kernel.org/stable/c/c844b7d9a9586de15dd28c06da5cc7f6ab28787d
https://git.kernel.org/stable/c/c17f06d8a085d6be58b544a440ce243f5e441a60
https://git.kernel.org/stable/c/b983c56426383e4a06fa5970c4e33cee879b1482
reply other threads:[~2026-08-15 6:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026081508-CVE-2026-72010-0203@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.