Live › vulnerability › CVE-2026-98972
Go to dashboardIn the Linux kernel cpuset controller, the is_in_v2_mode() helper could read a cgroup root pointer that is stale while a cgroup filesystem is being rebound. The fix replaces that read with a dedicated cpuset_v2_mode flag, which avoids a potential use-after-free; the sources do not state a direct attacker outcome.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the cpuset cgroup controller and the cpuset_v2_mode mount option path are the ones the fix concerns. The sources do not say which kernel versions are vulnerable or how an attacker would trigger the stale pointer, so teams can not yet confirm who can skip it.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Don't access cpuset_cgrp_subsys.root in is_in_v2_mode()
After seeing the patch [1] to guard is_in_v2_mode() with RCU, it makes me realize that is_in_v2_mode() may be called in a context where a new cgroup filesystem is being rebound with stale cpuset_cgrp_subsys.root pointer. Avoid this potential UaF situation by adding a new cpuset_v2_mode flag which is set when the cpuset_v2_mode mount option is used. This flag is written into only when cpuset_bind() is being called with a stable cpuset_cgrp_subsys.root value. The is_in_v2_mode() helper is modified to read the new cpuset_v2_mode flag instead of accessing cpuset_cgrp_subsys.root directly.
This page as .md · .json · in your agent: get_signal("CVE-2026-98972")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.