Affected: AlmaLinux:8: aardvark-dns, AlmaLinux:8: buildah, AlmaLinux:8: buildah-tests, AlmaLinux:8: cockpit-podman, AlmaLinux:8: conmon, AlmaLinux:8: container-selinux, AlmaLinux:8: containernetworking-plugins, AlmaLinux:8: containers-common, AlmaLinux:8: crit, AlmaLinux:8: criu and 24 more

The container-tools module contains tools for working with containers, notably podman, buildah, skopeo, and runc.

Security Fix(es):

* cri-o: memory exhaustion on the node when access to the kube api (CVE-2022-1708) * golang: crash in a golang.org/x/crypto/ssh server (CVE-2022-27191) * runc: incorrect handling of inheritable capabilities (CVE-2022-29162)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Additional Changes:

For detailed information on changes in this release, see the AlmaLinux Release Notes linked from the References section.

A vulnerability was found in CRI-O that causes memory or disk space exhaustion on the node for anyone with access to the Kube API. The ExecSync request runs commands in a container and logs the output of the command. This output is then read by CRI-O after command execution, and it is read in a manner where the entire file corresponding to the output of the command is read in. Thus, if the output of the command is large it is possible to exhaust the memory or the disk space of the node when CRI-O reads the output of the command. The highest threat from this vulnerability is system availability.

Affected: Go: github.com/cri-o/cri-o

### Description An ExecSync request runs a command in a container and returns the output to the Kubelet. It is used for readiness and liveness probes within a pod. The way CRI-O runs ExecSync commands is through conmon. CRI-O asks conmon to start the process, and conmon writes the output to disk. CRI-O then reads the output and returns it to the Kubelet.

If the output of the command is large enough, it is possible to exhaust the memory (or disk usage) of the node. The following deployment is an example yaml file that will output around 8GB of ‘A’ characters, which would be written to disk by conmon and read by CRI-O.

```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment100 spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 lifecycle: postStart: exec: command: ["/bin/sh", "-c", "seq 1 50000000`; do echo -n 'aaaaaaaaaaaaaaaa'; done"] ```

### Impact It is possible for the node to be exhausted of memory or disk space, depending on the node the command is being run on. What is further problematic is that the memory and disk usage aren't attributed to the container, as this file and its processing are implementation details of CRI-O. The consequence of the exhaustion is that other services on the node, e.g. other containers, will be unable to allocate memory and…

conmon-2.1.2-1.1 on GA media

cri-o: memory exhaustion on the node when access to the kube api

Security update for conmon