https://github.com/containers/bubblewrap/security/advisories/GHSA-xq78-7hw4-5jvp Vulnerable: bubblewrap >= 0.11.0 if installed setuid Fixed: bubblewrap >= 0.11.2 Not believed to be vulnerable: bubblewrap < 0.11.0

Impact

A truncated TCP DNS query followed by a connection reset causes aardvark-dns to enter an unrecoverable infinite error loop at 100% CPU.

Patches https://github.com/containers/aardvark-dns/commit/3b49ea7b38bdea134b7f03256f2e13f44ce73bb1

Workarounds None

Credits

Thanks to @dkane01 for reporting this

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 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 flaw was found in Aardvark-dns versions 1.12.0 and 1.12.1. They contain a denial of service vulnerability due to serial processing of TCP DNS queries. This flaw allows a malicious client to keep a TCP connection open indefinitely, causing other DNS queries to time out and resulting in a denial of service for all other containers using aardvark-dns.

This flaw was found in Buildah via podman,. Type: information disclosure of a local absolute path Severity: very low. (A local path is not that sensitive information). Feel free to just disregard this report if you think this issue has too low importance. Summary: Podman may disclose the absolute path of an empty context dir when running "podman --remote build -t test1 -f /tmp/Dockerfile emptydir". The path could be logged in the container image. (The lowest subdirectory of the absolute path might not be disclosed, see discussion below) The issue was introduced in https://github.com/containers/podman/pull/13531 that went into the Podman release v4.1.0-rc1

'podman cp' will resolve a carefully crafted symlink in host-filesystem space, yielding unexpected results when cp'ing from container to host. An attacker could create a container image containing particular symlinks that, when copied by a victim user to the host filesystem, may overwrite existing files with others from the host.

Upstream Issue: https://github.com/containers/libpod/issues/3829