Database/Kernel, userspace & hypervisor
Linux kernel (cgroups v1): cgroups v1 release_agent lets a container with CAP_SYS_ADMIN (or an unconfined userns) run
Impact
cgroups v1 release_agent lets a container with CAP_SYS_ADMIN (or an unconfined userns) run arbitrary host-root commands [KEV]
Who can reach it
Any tenant process in a container
What to do
Livepatchable; otherwise drain + reboot. Strong compensating controls: cgroup v2 only, seccomp/AppArmor default profiles, drop CAP_SYS_ADMIN
Fleet impact
How widespread
Universal - the release_agent path exists on every pre-5.17 kernel; cgroups v1 was still the default on most GPU host images
Cost to remediate
node-reboot - kernel upgrade; the only mitigation is relying on AppArmor/SELinux/seccomp being correctly applied, which is exactly what privileged AI workloads often disable
Why it hits the whole fleet
A root-in-container process abuses user namespaces to mount cgroups v1, sets release_agent and runs arbitrary commands as host root; GPU containers routinely run privileged or with --cap-add, which removes the default hardening that would have blocked it
References
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.