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.
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 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.
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?
Impact What kind of vulnerability is it? Who is impacted? All versions of CRI-O running on cgroupv2 nodes. Unchecked access to an experimental annotation allows a container to be unconfined. Back in 2021, support was added to support an experimental annotation that allows a user to request special resources in cgroupv2. It was supposed to be gated by an experimental annotation: io.kubernetes.cri-o.UnifiedCgroup, which was supposed to be filtered from the list of allowed annotations . However, there is a bug in this code which allows any user to specify this annotation, regardless of whether it's enabled on the node. The consequences of this are a pod can specify any amount of memory/cpu and get it, circumventing the kubernetes scheduler, and potentially be able to DOS a node. Patches Has the problem been patched? What versions should users upgrade to? 1.29.1, 1.28.3, 1.27.3
Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? use cgroupv1
References Are there any links users can visit to find out more?