GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux cgroup freezer: lock inversion between cpu_hotplug_lock and freezer_mutex can deadlock

CVSS 7.8CVE-2023-53522Kernel, userspace & hypervisorcurated

Impact

After the core freezer rewrite, freezer_apply_state() takes cpu_hotplug_lock while already holding freezer_mutex, while the cgroup attach path takes them in the opposite order. A workload that writes to cgroup v1 freezer state concurrently with task migration can deadlock those locks. On a GPU node this is a hang in the cgroup machinery the container runtime drives on every pod start and stop, so the node stops accepting or releasing work and has to be rebooted - expensive on a box with long-running training jobs. Availability only; no memory corruption or information disclosure is described.

Who can reach it

Local. Needs write access to cgroup v1 freezer files plus concurrent task attachment - normally the container runtime or a privileged process, not an unprivileged tenant inside a pod.

What to do

Patch the host kernel to a stable release that moves cpus_read_lock() outside freezer_mutex, then drain and reboot the node. Hosts on cgroup v2 only are not affected by the freezer v1 path.

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.