GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel cpuset: attaching a task to a cgroup v2 cpuset with an empty cpus_allowed panics the host

CVSS 7.1CVE-2022-50103Kernel, userspace & hypervisorcurated

Impact

Under cgroup v2 a cpuset's cpus_allowed can legitimately be empty, meaning "inherit the parent's effective CPUs". cpuset_can_attach() passed that empty mask to task_can_attach(), so cpumask_any_and() returned nr_cpu_ids and dl_bw_of() dereferenced a per-CPU pointer for an out-of-range CPU, faulting in dl_cpu_busy(). The result is a host kernel oops reached through an ordinary write to cgroupfs, which on a GPU node means every tenant pod on that node goes down together and the node has to come back through a reboot. There is no information disclosure here - the exposure is availability of a shared node, and GPU nodes with pinned CPU sets and delegated cgroup subtrees are exactly where empty cpusets occur.

Who can reach it

Local. Anyone able to write the cgroup v2 control files for a cpuset subtree - the container runtime, the kubelet, systemd, or a tenant handed a delegated cgroup subtree - can attach a task to a cpuset whose cpus_allowed is empty. No remote access and no privilege beyond write access to that cgroup hierarchy.

What to do

Update to a stable kernel that carries the fix (task_can_attach() now takes cs_effective_cpus and also guards against cpumask_any_and() returning >= nr_cpu_ids) and reboot each node; there is no runtime mitigation short of not delegating cpuset subtrees. Plan it as a rolling drain-and-reboot across the fleet - the fix is in the scheduler core and cannot be hot-patched by restarting a daemon. The stable commits are listed in the references; no vendor advisory names a single fixed release.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.