Re: [PATCH] mm: don't allow empty relative nodemask in mpol_relative_nodemask()

[Gregory Price <gourry@gourry.net>]

On Tue, Jun 02, 2026 at 11:19:49AM +0200, David Hildenbrand (Arm) wrote:
> 
> According to the report [1] syzkaller can trigger it. There is no reproducer,
> though.
> 
> [1]
> https://lore.kernel.org/all/CA+0ovCgxbZkXa+OU8w3s84R3KNPNxxRfmsNR-udh+afQBbGNmw@mail.gmail.com/
>

The actual implication of this report is that there is a bug in cpuset,
not mempolicy.  

  mpol_rebind_mm+0x3ab/0x680 mm/mempolicy.c:569
      ^^^ should never receive a 0-node nodemask ^^^
  ...snip...
  cpuset_update_tasks_nodemask+0x22e/0x340 kernel/cgroup/cpuset.c:2777
      ^^^ calls guarantee_online_mems ^^^
  ...snip...
  hotplug_update_tasks kernel/cgroup/cpuset.c:3882 [inline]
  cpuset_hotplug_update_tasks kernel/cgroup/cpuset.c:3985 [inline]

Relevant code:

void cpuset_update_tasks_nodemask(struct cpuset *cs)
{
... snip ...
        guarantee_online_mems(cs, &newmems); <<< critical call
... snip ...
        while ((task = css_task_iter_next(&it))) {
... snip ...
                mpol_rebind_mm(mm, &cs->mems_allowed);

Seems like maybe mpol_rebind_mm should be called with newmems, not
cs->mems_allowed, though cs->mems_allowed should never be allowed to be
empty, because that makes no sense.

Just eyeballing it, I can't say whether calling with newmems is the
right thing, or if mems_allowed should not be allowed to be empty, would
have to dig in a little further.

~Gregory