Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact youki’s apparmor handling performs insufficiently strict write-target validation, which—combined with path substitution during pathname resolution—can allow writes to unintended procfs locations. Weak write-target check youki only verifies that the destination lies somewhere under procfs. As a result, a write intended for /proc/self/attr/apparmor/exec can succeed even if the path has been redirected to /proc/sys/kernel/hostname(which is also in procfs). Path substitution While resolving a path component-by-component, a shared-mount race can substitute intermediate components and redirect the final target. This is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems. https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm Credits Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@tonistiigi from Docker) for…
Recommended action: Upgrade to 0.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact youki utilizes bind mounting the container's /dev/null as a file mask. When performing this operation, the initial validation of the source /dev/null was insufficient. Specifically, we initially failed to verify whether /dev/null was genuinely present. However, we did perform validation to ensure that the /dev/null path existed within the container, including checking for symbolic links. Additionally, there was a vulnerability in the timing between validation and the actual mount operation. As a result, by replacing /dev/null with a symbolic link, we can bind-mount arbitrary files from the host system. This is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems. https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2 Credits Thanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original runc's vulnerability (Attack…
Recommended action: Upgrade to 0.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If /proc and /sys in the rootfs are symbolic links, they can potentially be exploited to gain access to the host root filesystem. Details For security reasons, container creation should be prohibited if /proc or /sys in the rootfs is a symbolic link. I verified this behavior with youki. When /proc or /sys is a symbolic link, runc fails to create the container, whereas youki successfully creates it. This is the fix related to this issue in runc. https://github.com/opencontainers/runc/pull/3756 https://github.com/opencontainers/runc/pull/3773 https://github.com/opencontainers/runc/blob/main/libcontainer/rootfslinux.go#L590 https://github.com/opencontainers/runc/blob/main/tests/integration/mask.bats#L60 Impact The following advisory appears to be related to this vulnerability: https://github.com/advisories/GHSA-vpvm-3wq2-2wvm https://github.com/advisories/GHSA-fh74-hm69-rqjw
Recommended action: Upgrade to 0.5.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.