QID 355440

runc is a cli tool for spawning and running containers according to the oci specification.
In affected versions it was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1.
When runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with rootless docker/podman/nerdctl) or 2.
When runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc spec --rootless`; this condition is very rare).
A container may gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host .
Other userss cgroup hierarchies are not affected.
Users are advised to upgrade to version 1.1.5.
Users unable to upgrade may unshare the cgroup namespace (`(docker|podman|nerdctl) run --cgroupns=private)`.
This is the default behavior of docker/podman/nerdctl on cgroup v2 hosts.
Or add `/sys/fs/cgroup` to `maskedpaths`. (
( CVE-2023-25809) runc through 1.1.4 has incorrect access control leading to escalation of privileges, related to libcontainer/rootfs_linux.go.
To exploit this, an attacker must be able to spawn two containers with custom volume-mount configurations, and be able to run custom images.
Note: this issue exists because of a( CVE-2019-19921 regression. (
( CVE-2023-27561) runc is a cli tool for spawning and running containers according to the oci specification.
It was found that apparmor can be bypassed when `/proc` inside the container is symlinked with a specific mount configuration.
This issue has been fixed in runc version 1.1.5, by prohibiting symlinked `/proc`.

Note: The preceding description block is extracted directly from the security advisory. Using automation, we have attempted to clean and format it as much as possible without introducing additional issues.

Successful exploitation of this vulnerability could lead to a securitybreach or could affect integrity, availability, and confidentiality.