https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 09:18:58 +0000 https://vulnerability.circl.lu/vuln/cve-2024-43853 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cgroup/cpuset: Prevent UAF in proc_cpuset_show()</p> <p>An UAF can happen when /proc/cpuset is read as reported in [1].</p> <p>This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc/&lt;pid&gt;/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly.</p> <p>The race that cause this bug can be shown as below:</p> <p>(umount) | (cat /proc/&lt;pid&gt;/cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css-&gt;cgroup, ...); cgroup_destroy_root | mutex_lock(&amp;cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..);</p> <p>When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &amp;cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &amp;cgrp_dfl_root.cgrp.</p> <p>The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However,…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>cgroup/cpuset: Prevent UAF in proc_cpuset_show()</p> <p>An UAF can happen when /proc/cpuset is read as reported in [1].</p> <p>This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc/&lt;pid&gt;/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly.</p> <p>The race that cause this bug can be shown as below:</p> <p>(umount) | (cat /proc/&lt;pid&gt;/cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css-&gt;cgroup, ...); cgroup_destroy_root | mutex_lock(&amp;cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..);</p> <p>When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &amp;cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &amp;cgrp_dfl_root.cgrp.</p> <p>The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However,…</p> https://vulnerability.circl.lu/vuln/cve-2024-43853