crypto: algifaead - Revert to operating out-of-place

A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.

A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.

Impact A malicious container can affect the host by taking advantage of code cri-o added to show the container mounts on the host.

A workload built from this Dockerfile: FROM docker.io/library/busybox as source RUN mkdir /extra && cd /extra && ln -s ../../../../../../../../root etc

FROM scratch

COPY --from=source /bin /bin COPY --from=source /lib /lib COPY --from=source /extra .

and this container config:

{ "metadata": { "name": "busybox" }, "image":{ "image": "localhost/test" }, "command": [ "/bin/true" ], "linux": { } }

and this sandbox config { "metadata": { "name": "test-sandbox", "namespace": "default", "attempt": 1, "uid": "edishd83djaideaduwk28bcsb" }, "linux": { "securitycontext": { "namespaceoptions": { "network": 2 } } } }

will create a file on host /host/mtab

Patches 1.30.1, 1.29.5, 1.28.7

Workarounds Unfortunately not

References Are there any links users can visit to find out more?

A flaw in the containers/common Go library, used by container runtimes such as Podman, Buildah, and CRI-O, allows a malicious container image to exploit the FIPS mode to bind mount arbitrary host directories into the container. The flaw arises from the MountsWithUIDGID() function, which attempts to mount a FIPS-related directory inside the container but does not properly verify the path. If the FIPS path is a symlink, it could point to arbitrary directories on the host, allowing an attacker to access sensitive host files.

A vulnerability was found in Buildah. Cache mounts do not properly validate that user-specified paths for the cache are within our cache directory, allowing a RUN instruction in a Container file to mount an arbitrary directory from the host (read/write) into the container as long as those files can be accessed by the user running Buildah.

A symlink traversal vulnerability in the containers/storage library can cause Podman, Buildah, and CRI-O to hang and potentially be DoSed via OOM kill when running a malicious image using an automatically assigned user namespace (--userns=auto in Podman and Buildah). The containers/storage library will read /etc/passwd inside the container, but does not properly validate if that file is a symlink, which can be used to cause the library to read an arbitrary file on the host. This file is only read, and if it does not properly parse as a copy of /etc/passwd it will cause an error (there is a small risk of information disclosure via the error message here as elements of the file that failed to parse can be included, but this is only as the user running Podman/Buildah/CRI-O so it wouldn't be a file they did not already have access to). The report here discovered that you can symlink /etc/passwd in the container to a FIFO on the host, causing a hang as the file cannot be completely read (or an OOM condition if the FIFO is continuously written to, which was then ready by Podman). This hang could occur in a critical section in the c/storage library, blocking other processes from creating containers, but could be easily solved via a SIGKILL of the affected process. The ability to potentially crash the CRI-O service via OOM kill could be more relevant, though the attacker would have to know the path of a FIFO that is regularly being written to on the host in order to do this.