CVE-2026-98542: cgroup/cpuset: Return PERR_NOCPUS in remote_partition_enable() on subpartitions_cpus conflict
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Return PERRNOCPUS in remotepartitionenable() on subpartitionscpus conflict
When a remote partition is created underneath an existing local partition via a non-partition (PRSMEMBER) intermediate cgroup, updateprstate() sees parent->partitionrootstate == PRSMEMBER and calls remotepartitionenable().
Commit 86888c7bd117 ("cgroup/cpuset: Add warnings to catch inconsistency in exclusive CPUs") replaced the cpumaskintersects(tmp->newcpus, subpartitionscpus) error check in remotepartitionenable() with WARNONONCE(). As a result, remotepartitionenable() emits a warning and proceeds to enable the remote partition on CPUs that are already owned by the ancestor local partition in subpartitionscpus.
This can be reproduced on Linux 7.3.0-rc3 with:
mkdir -p /tmp/cg1 mount -t cgroup2 none /tmp/cg1 echo "+cpuset" > /tmp/cg1/cgroup.subtreecontrol
mkdir /tmp/cg1/A echo 1 > /tmp/cg1/A/cpuset.cpus echo 1 > /tmp/cg1/A/cpuset.cpus.exclusive echo root > /tmp/cg1/A/cpuset.cpus.partition echo "+cpuset" > /tmp/cg1/A/cgroup.subtreecontrol
mkdir /tmp/cg1/A/B echo 1 > /tmp/cg1/A/B/cpuset.cpus echo 1 > /tmp/cg1/A/B/cpuset.cpus.exclusive echo "+cpuset" > /tmp/cg1/A/B/cgroup.subtreecontrol
mkdir /tmp/cg1/A/B/D echo 1 > /tmp/cg1/A/B/D/cpuset.cpus echo 1 > /tmp/cg1/A/B/D/cpuset.cpus.exclusive echo root > /tmp/cg1/A/B/D/cpuset.cpus.partition
which triggers:
WARNING: kernel/cgroup/cpuset.c:1594 at remotepartitionenable+0x1c1/0x300
and leaves both /tmp/cg1/A and /tmp/cg1/A/B/D as active root partitions claiming exclusive CPU 1.
Fix this by returning PERRNOCPUS when tmp->newcpus intersects subpartitionscpus in remotepartitionenable(), matching the error code used by remotecpusupdate() for the same subpartitionscpus conflict, and add a regression test case to tools/testing/selftests/cgroup/testcpusetprs.sh.
Tested in QEMU on Linux 7.3.0-rc3 using the reproducer above and tools/testing/selftests/cgroup/testcpusetprs.sh.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which systems are exposed to this condition?
The affected configuration uses cgroup v2 with the cpuset controller enabled and a hierarchy where a remote partition is created below an existing local partition through a non-partition (PRS_MEMBER) intermediate cgroup. The supplied reproduction demonstrates this on Linux 7.3.0-rc3.
What access is needed to trigger it?
An actor needs the ability to create and configure cgroup v2 directories and write cpuset CPU, exclusivity, partition, and subtree-control settings. The trigger relies on assigning CPUs that are already owned by an ancestor local partition to the remote partition.
How can administrators identify a potentially affected system?
A potentially affected system may emit a warning from remote_partition_enable() when its new CPU mask intersects subpartitions_cpus. The problematic state is a remote partition being enabled on CPUs already owned by its ancestor local partition.
What behavior does the fix restore?
The fix returns PERR_NOCPUS for the subpartitions_cpus conflict instead of only issuing WARN_ON_ONCE() and continuing. This prevents the remote partition from being enabled with CPUs already owned by the ancestor local partition.