)]}'
{
  "commit": "6f363f5aa845561f7ea496d8b1175e3204470486",
  "tree": "5f708a9375f3c7145c65dd6a5f5e6cda65194094",
  "parents": [
    "f0cc749254d12c78e93dae3b27b21dc9546843d0"
  ],
  "author": {
    "name": "Xiu Jianfeng",
    "email": "xiujianfeng@huawei.com",
    "time": "Sat Jun 10 17:26:43 2023 +0800"
  },
  "committer": {
    "name": "Tejun Heo",
    "email": "tj@kernel.org",
    "time": "Mon Jun 12 07:21:57 2023 -1000"
  },
  "message": "cgroup: Do not corrupt task iteration when rebinding subsystem\n\nWe found a refcount UAF bug as follows:\n\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 1 PID: 342 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x148\nWorkqueue: events cpuset_hotplug_workfn\nCall trace:\n refcount_warn_saturate+0xa0/0x148\n __refcount_add.constprop.0+0x5c/0x80\n css_task_iter_advance_css_set+0xd8/0x210\n css_task_iter_advance+0xa8/0x120\n css_task_iter_next+0x94/0x158\n update_tasks_root_domain+0x58/0x98\n rebuild_root_domains+0xa0/0x1b0\n rebuild_sched_domains_locked+0x144/0x188\n cpuset_hotplug_workfn+0x138/0x5a0\n process_one_work+0x1e8/0x448\n worker_thread+0x228/0x3e0\n kthread+0xe0/0xf0\n ret_from_fork+0x10/0x20\n\nthen a kernel panic will be triggered as below:\n\nUnable to handle kernel paging request at virtual address 00000000c0000010\nCall trace:\n cgroup_apply_control_disable+0xa4/0x16c\n rebind_subsystems+0x224/0x590\n cgroup_destroy_root+0x64/0x2e0\n css_free_rwork_fn+0x198/0x2a0\n process_one_work+0x1d4/0x4bc\n worker_thread+0x158/0x410\n kthread+0x108/0x13c\n ret_from_fork+0x10/0x18\n\nThe race that cause this bug can be shown as below:\n\n(hotplug cpu)                | (umount cpuset)\nmutex_lock(\u0026cpuset_mutex)    | mutex_lock(\u0026cgroup_mutex)\ncpuset_hotplug_workfn        |\n rebuild_root_domains        |  rebind_subsystems\n  update_tasks_root_domain   |   spin_lock_irq(\u0026css_set_lock)\n   css_task_iter_start       |    list_move_tail(\u0026cset-\u003ee_cset_node[ss-\u003eid]\n   while(css_task_iter_next) |                  \u0026dcgrp-\u003ee_csets[ss-\u003eid]);\n   css_task_iter_end         |   spin_unlock_irq(\u0026css_set_lock)\nmutex_unlock(\u0026cpuset_mutex)  | mutex_unlock(\u0026cgroup_mutex)\n\nInside css_task_iter_start/next/end, css_set_lock is hold and then\nreleased, so when iterating task(left side), the css_set may be moved to\nanother list(right side), then it-\u003ecset_head points to the old list head\nand it-\u003ecset_pos-\u003enext points to the head node of new list, which can\u0027t\nbe used as struct css_set.\n\nTo fix this issue, switch from all css_sets to only scgrp\u0027s css_sets to\npatch in-flight iterators to preserve correct iteration, and then\nupdate it-\u003ecset_head as well.\n\nReported-by: Gaosheng Cui \u003ccuigaosheng1@huawei.com\u003e\nLink: https://www.spinics.net/lists/cgroups/msg37935.html\nSuggested-by: Michal Koutný \u003cmkoutny@suse.com\u003e\nLink: https://lore.kernel.org/all/20230526114139.70274-1-xiujianfeng@huaweicloud.com/\nSigned-off-by: Xiu Jianfeng \u003cxiujianfeng@huawei.com\u003e\nFixes: 2d8f243a5e6e (\"cgroup: implement cgroup-\u003ee_csets[]\")\nCc: stable@vger.kernel.org # v3.16+\nSigned-off-by: Tejun Heo \u003ctj@kernel.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "245cf62ce85aee10bbc0e9e436c2334be9fdc088",
      "old_mode": 33188,
      "old_path": "kernel/cgroup/cgroup.c",
      "new_id": "4d42f0cbc11ea33b2a2ca7a6c023a1c94d90e4b9",
      "new_mode": 33188,
      "new_path": "kernel/cgroup/cgroup.c"
    }
  ]
}