The vulnerability description states that containerd's CRI implementation incorrectly assigns cgroup hierarchy for containers in user-namespaced Kubernetes pods. This leads to Kubernetes limits not being honored. The fix involves correcting how the cgroup path is determined and applied for such pods.

I was unable to fetch commit details using get_commit_infos for the specific fixing commits (323c7000098791211342117187b0979777510091 or its cherry-pick c9198302594581cf598508e8a39999807998c880). However, by manually reviewing the GitHub Pull Request #10014 (cri: fix cgroup path for userns sandboxes) and its cherry-pick to the release branch #11708, which are cited by the GHSA advisory GHSA-cxfp-7pvr-95ff as the fix, I identified the modified files and functions.

The primary changes are in pkg/cri/server/helpers_linux.go within the applySandboxResources function, and in pkg/cri/server/sandbox_run_linux.go within the (*criService).runPodSandbox method.

1. applySandboxResources: This function calculates and applies resource configurations, including the cgroup path. The patch modifies the logic to correctly derive the cgroupPath when user namespaces are in use, specifically by using the parent directory of the configured CgroupsPath for user-namespaced pods. This directly addresses the incorrect hierarchy assignment.

2. (*criService).runPodSandbox: This method is a core part of creating sandboxes. It was modified to conditionally skip the creation of the sandbox's own cgroup directory if user namespaces are enabled (if !usernsPod(...)). This is because, in user-namespaced scenarios, the sandbox itself doesn't get its own dedicated cgroup in the same way; containers within it are managed under the pod-level cgroup.

These two functions are central to how cgroups are handled for sandboxes in the CRI plugin, and the changes directly address the described problem of incorrect cgroup path assignment for user-namespaced pods.