Akihirosuda

**Name of the Vulnerable Software and Affected Versions** CRI-O Container Engine versions prior to the fixed version **Description** A flaw was found in CRI-O, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. This can be achieved by adding annotations such as `org.systemd.property.SuccessAction` to a Pod, allowing for the execution of arbitrary commands on the host system. **Recommendations** For CRI-O Container Engine versions prior to the fixed version, consider implementing an external mutating webhook to disallow annotations with the prefix "org.systemd.property." to prevent exploitation. Unfortunately, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Lima versions prior to 0.16.0 **Description** A virtual machine instance with a malicious disk image could read a single file on the host filesystem, even when no filesystem is mounted from the host. The attacker has to embed the target file path in a malicious disk image, as the qcow2 (or vmdk) backing file path string. Lima refuses to run as the root, making it practically impossible for the attacker to read the entire host disk via `/dev/rdiskN`. The attacker also cannot read at least the first 512 bytes (MBR) of the target file. **Recommendations** For versions prior to 0.16.0, update to version 0.16.0 or later, which prohibits using a backing file path in the VM base image. As a temporary workaround, do not use an untrusted disk image.

**Name of the Vulnerable Software and Affected Versions** runc versions prior to 1.1.5 **Description** The issue is related to rootless runc making `/sys/fs/cgroup` writable under certain conditions, specifically when runc is executed inside the user namespace and the `config.json` does not specify the cgroup namespace to be unshared, or when runc is executed outside the user namespace and `/sys` is mounted with `rbind, ro`. This allows a container to gain write access to the user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host. Other users' cgroup hierarchies are not affected. **Recommendations** To resolve the issue, upgrade to version 1.1.5. For versions prior to 1.1.5, unshare the cgroup namespace by running `(docker|podman|nerdctl) run --cgroupns=private`. Alternatively, add `/sys/fs/cgroup` to `maskedPaths`.