Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 7aae4db5 authored by Neeraj Upadhyay's avatar Neeraj Upadhyay Committed by ivanmeler
Browse files

cgroup: Fix potential race between cgroup_exit and migrate path



There is a potential race between cgroup_exit() and the
migration path. This race happens because cgroup_exit path
reads the css_set and does cg_list empty check outside of
css_set lock. This can potentially race with the migrate path
trying to move the tasks to a different css_set. For instance,
below is the interleaved sequence of events, where race is
observed:

cpuset_hotplug_workfn()
  cgroup_transfer_tasks()
    cgroup_migrate()
      cgroup_taskset_migrate()
          css_set_move_task()
            list_del_init(&task->cg_list);
            <TASK EXIT>
              cgroup_exit()
                cset = task_css_set(tsk);
                if (!list_empty(&tsk->cg_list))
                <TASK NOT DISSOCIATED FROM ITS CSS_SET>
            list_add_tail(&task->cg_list, use_mg_tasks

In above sequence, as cgroup_exit() read the cg_list for
the task as empty, it didn't disassociate it from its
current css_set, and was moved to new css_set instance
css_set_move_task() called from cpuset_hotplug_workfn()
path. This eventually can result in use after free scenarios,
while accessing the same task_struct again, like in following
sequence:

kernfs_seq_start()
  cgroup_seqfile_start()
    cgroup_pidlist_start()
      css_task_iter_next()
        __put_task_struct()
          <NULL pointer dereference>

Fix this problem, by moving the css_set and cg_list fetch in
cgroup_exit() inside css_set lock.

Change-Id: I66060b8faffc06ffb19e2c166013551d4c9cb746
Signed-off-by: default avatarNeeraj Upadhyay <neeraju@codeaurora.org>
parent fd37bcd7
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment