| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-skip-test-hugetlb_test.go-random-failures-on-ppc64el.patch | skip test: hugetlb_test.go, random failures on ppc64el, s390x | Dmitry Smirnov <onlyjob@debian.org> | not-needed | 2018-09-27 | ||
| 0002-skip-privileged-test-TestFactoryNewTmpfs.patch | skip privileged test: TestFactoryNewTmpfs | Dmitry Smirnov <onlyjob@debian.org> | not-needed | 2018-06-15 | ||
| 0003-fix-gccgo.patch | fix gccgo | Shengjing Zhu <zhsj@debian.org> | yes | 2020-04-27 | ||
| 0004-skip-privileged-test-nsenter_test.go.patch | skip privileged test: nsenter_test.go | Shengjing Zhu <zhsj@debian.org> | no | 2021-01-23 | ||
| 0005-skip-privileged-test-fs_test.go.patch | skip privileged test: fs_test.go | Shengjing Zhu <zhsj@debian.org> | no | 2021-01-23 | ||
| 0006-skip-privileged-test-fscommon_test.go.patch | skip privileged test: fscommon_test.go | Shengjing Zhu <zhsj@debian.org> | no | 2021-01-23 | ||
| 0007-skip-test-cgroups_test.go-fail-when-cgroups-is-not-m.patch | skip test: cgroups_test.go, fail when cgroups is not mounted | Shengjing Zhu <zhsj@debian.org> | no | 2021-01-23 | ||
| 0008-fix-patchpbf-test-on-32-bit.patch | fix patchpbf test on 32-bit | Aleksa Sarai <asarai@suse.de> | no | https://github.com/opencontainers/runc/pull/2768/commits/47a96495208f5dfdceabc1a2acbfa1c0517aac80 | 2021-02-02 | |
| 0009-skip-integration-when-no-dev-kmsg.patch | skip integration when no /dev/kmsg By default, privileged lxc container doesn't have /dev/kmsg |
Shengjing Zhu <zhsj@debian.org> | no | 2021-02-04 | ||
| 0010-Ensure-the-seccomp-pipe-is-being-read-while-exportin.patch | Ensure the seccomp pipe is being read while exporting bpf | Shengjing Zhu <zhsj@debian.org> | no | backport, https://github.com/opencontainers/runc/pull/2871 | 2021-04-10 | |
| CVE-2021-30465/rc93-0001-libct-newInitConfig-nit.patch | [PATCH 1/5] libct/newInitConfig: nit Move the initialization of Console* fields as they are unconditional. |
Kir Kolyshkin <kolyshkin@gmail.com> | no | 2021-02-23 | ||
| CVE-2021-30465/rc93-0002-libct-rootfs-introduce-and-use-mountConfig.patch | [PATCH 2/5] libct/rootfs: introduce and use mountConfig The code is already passing three parameters around from mountToRootfs to mountCgroupV* to mountToRootfs again. I am about to add another parameter, so let's introduce and use struct mountConfig to pass around. |
Kir Kolyshkin <kolyshkin@gmail.com> | no | 2021-02-23 | ||
| CVE-2021-30465/rc93-0003-libct-rootfs-mountCgroupV2-minor-refactor.patch | [PATCH 3/5] libct/rootfs/mountCgroupV2: minor refactor 1. s/cgroupPath/dest/ 2. don't hardcode /sys/fs/cgroup |
Kir Kolyshkin <kolyshkin@gmail.com> | no | 2021-02-23 | ||
| CVE-2021-30465/rc93-0004-Fix-cgroup2-mount-for-rootless-case.patch | [PATCH 4/5] Fix cgroup2 mount for rootless case In case of rootless, cgroup2 mount is not possible (see [1] for more details), so since commit 9c81440fb5a7 runc bind-mounts the whole /sys/fs/cgroup into container. Problem is, if cgroupns is enabled, /sys/fs/cgroup inside the container is supposed to show the cgroup files for this cgroup, not the root one. The fix is to pass through and use the cgroup path in case cgroup2 mount failed, cgroupns is enabled, and the path is non-empty. Surely this requires the /sys/fs/cgroup mount in the spec, so modify runc spec --rootless to keep it. Before: $ ./runc run aaa # find /sys/fs/cgroup/ -type d /sys/fs/cgroup /sys/fs/cgroup/user.slice /sys/fs/cgroup/user.slice/user-1000.slice /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service ... # ls -l /sys/fs/cgroup/cgroup.controllers -r--r--r-- 1 nobody nogroup 0 Feb 24 02:22 /sys/fs/cgroup/cgroup.controllers # wc -w /sys/fs/cgroup/cgroup.procs 142 /sys/fs/cgroup/cgroup.procs # cat /sys/fs/cgroup/memory.current cat: can't open '/sys/fs/cgroup/memory.current': No such file or directory After: # find /sys/fs/cgroup/ -type d /sys/fs/cgroup/ # ls -l /sys/fs/cgroup/cgroup.controllers -r--r--r-- 1 root root 0 Feb 24 02:43 /sys/fs/cgroup/cgroup.controllers # wc -w /sys/fs/cgroup/cgroup.procs 2 /sys/fs/cgroup/cgroup.procs # cat /sys/fs/cgroup/memory.current 577536 [1] https://github.com/opencontainers/runc/issues/2158 |
Kir Kolyshkin <kolyshkin@gmail.com> | no | 2021-02-23 | ||
| CVE-2021-30465/rc93-0005-rootfs-add-mount-destination-validation.patch | [PATCH 5/5] rootfs: add mount destination validation Because the target of a mount is inside a container (which may be a volume that is shared with another container), there exists a race condition where the target of the mount may change to a path containing a symlink after we have sanitised the path -- resulting in us inadvertently mounting the path outside of the container. This is not immediately useful because we are in a mount namespace with MS_SLAVE mount propagation applied to "/", so we cannot mount on top of host paths in the host namespace. However, if any subsequent mountpoints in the configuration use a subdirectory of that host path as a source, those subsequent mounts will use an attacker-controlled source path (resolved within the host rootfs) -- allowing the bind-mounting of "/" into the container. While arguably configuration issues like this are not entirely within runc's threat model, within the context of Kubernetes (and possibly other container managers that provide semi-arbitrary container creation privileges to untrusted users) this is a legitimate issue. Since we cannot block mounting from the host into the container, we need to block the first stage of this attack (mounting onto a path outside the container). The long-term plan to solve this would be to migrate to libpathrs, but as a stop-gap we implement libpathrs-like path verification through readlink(/proc/self/fd/$n) and then do mount operations through the procfd once it's been verified to be inside the container. The target could move after we've checked it, but if it is inside the container then we can assume that it is safe for the same reason that libpathrs operations would be safe. A slight wrinkle is the "copyup" functionality we provide for tmpfs, which is the only case where we want to do a mount on the host filesystem. To facilitate this, I split out the copy-up functionality entirely so that the logic isn't interspersed with the regular tmpfs logic. In addition, all dependencies on m.Destination being overwritten have been removed since that pattern was just begging to be a source of more mount-target bugs (we do still have to modify m.Destination for tmpfs-copyup but we only do it temporarily). |
Aleksa Sarai <cyphar@cyphar.com> | no | 2021-04-01 | ||
| default_retno.patch | commit c61f6062547d20b80a07e9593e9617e115773b28 libcontainer: honor seccomp defaultErrnoRet https://github.com/opencontainers/runtime-spec/pull/1087 added support for defaultErrnoRet to the OCI runtime specs. If a defaultErrnoRet is specified, disable patching the generated libseccomp cBPF. Closes: https://github.com/opencontainers/runc/issues/2943 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> |
Giuseppe Scrivano <gscrivan@redhat.com> | no | 2021-05-14 | ||
| CVE-2022-29162.patch | commit 364ec0f1b4fa188ad96049c590ecb42fa70ea165 runc: do not set inheritable capabilities Do not set inheritable capabilities in runc spec, runc exec --cap, and in libcontainer integration tests. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com> |
Kir Kolyshkin <kolyshkin@gmail.com> | no | 2022-03-01 | ||
| CVE-2024-21626/0018-Fix-File-to-Close.patch | Fix File to Close (This is a cherry-pick of 937ca107c3d22da77eb8e8030f2342253b980980.) |
"hang.jiang" <hang.jiang@daocloud.io> | no | 2023-09-01 | ||
| CVE-2024-21626/0019-init-verify-after-chdir-that-cwd-is-inside-the-conta.patch | init: verify after chdir that cwd is inside the container If a file descriptor of a directory in the host's mount namespace is leaked to runc init, a malicious config.json could use /proc/self/fd/... as a working directory to allow for host filesystem access after the container runs. This can also be exploited by a container process if it knows that an administrator will use "runc exec --cwd" and the target --cwd (the attacker can change that cwd to be a symlink pointing to /proc/self/fd/... and wait for the process to exec and then snoop on /proc/$pid/cwd to get access to the host). The former issue can lead to a critical vulnerability in Docker and Kubernetes, while the latter is a container breakout. We can (ab)use the fact that getcwd(2) on Linux detects this exact case, and getcwd(3) and Go's Getwd() return an error as a result. Thus, if we just do os.Getwd() after chdir we can easily detect this case and error out. In runc 1.1, a /sys/fs/cgroup handle happens to be leaked to "runc init", making this exploitable. On runc main it just so happens that the leaked /sys/fs/cgroup gets clobbered and thus this is only consistently exploitable for runc 1.1. [refactored the implementation and added more comments] |
Aleksa Sarai <cyphar@cyphar.com> | no | 2023-12-26 | ||
| CVE-2024-21626/0020-setns-init-do-explicit-lookup-of-execve-argument-ear.patch | setns init: do explicit lookup of execve argument early (This is a partial backport of a minor change included in commit dac41717465462b21fab5b5942fe4cb3f47d7e53.) This mirrors the logic in standard_init_linux.go, and also ensures that we do not call exec.LookPath in the final execve step. While this is okay for regular binaries, it seems exec.LookPath calls os.Getenv which tries to emit a log entry to the test harness when running in "go test" mode. In a future patch (in order to fix CVE-2024-21626), we will close all of the file descriptors immediately before execve, which would mean the file descriptor for test harness logging would be closed at execve time. So, moving exec.LookPath earlier is necessary. |
Aleksa Sarai <cyphar@cyphar.com> | no | 2024-01-05 | ||
| CVE-2024-21626/0021-init-close-internal-fds-before-execve.patch | init: close internal fds before execve If we leak a file descriptor referencing the host filesystem, an attacker could use a /proc/self/fd magic-link as the source for execve to execute a host binary in the container. This would allow the binary itself (or a process inside the container in the 'runc exec' case) to write to a host binary, leading to a container escape. The simple solution is to make sure we close all file descriptors immediately before the execve(2) step. Doing this earlier can lead to very serious issues in Go (as file descriptors can be reused, any (*os.File) reference could start silently operating on a different file) so we have to do it as late as possible. Unfortunately, there are some Go runtime file descriptors that we must not close (otherwise the Go scheduler panics randomly). The only way of being sure which file descriptors cannot be closed is to sneakily go:linkname the runtime internal "internal/poll.IsPollDescriptor" function. This is almost certainly not recommended but there isn't any other way to be absolutely sure, while also closing any other possible files. In addition, we can keep the logrus forwarding logfd open because you cannot execve a pipe and the contents of the pipe are so restricted (JSON-encoded in a format we pick) that it seems unlikely you could even construct shellcode. Closing the logfd causes issues if there is an error returned from execve. In mainline runc, runc-dmz protects us against this attack because the intermediate execve(2) closes all of the O_CLOEXEC internal runc file descriptors and thus runc-dmz cannot access them to attack the host. |
Aleksa Sarai <cyphar@cyphar.com> | no | 2024-01-02 | ||
| CVE-2024-21626/0022-cgroup-plug-leaks-of-sys-fs-cgroup-handle.patch | cgroup: plug leaks of /sys/fs/cgroup handle We auto-close this file descriptor in the final exec step, but it's probably a good idea to not possibly leak the file descriptor to "runc init" (we've had issues like this in the past) especially since it is a directory handle from the host mount namespace. In practice, on runc 1.1 this does leak to "runc init" but on main the handle has a low enough file descriptor that it gets clobbered by the ForkExec of "runc init". OPEN_TREE_CLONE would let us protect this handle even further, but the performance impact of creating an anonymous mount namespace is probably not worth it. Also, switch to using an *os.File for the handle so if it goes out of scope during setup (i.e. an error occurs during setup) it will get cleaned up by the GC. |
Aleksa Sarai <cyphar@cyphar.com> | no | 2023-12-26 | ||
| CVE-2024-21626/0023-libcontainer-mark-all-non-stdio-fds-O_CLOEXEC-before.patch | libcontainer: mark all non-stdio fds O_CLOEXEC before spawning init Given the core issue in GHSA-xr7r-f8xq-vfvv was that we were unknowingly leaking file descriptors to "runc init", it seems prudent to make sure we proactively prevent this in the future. The solution is to simply mark all non-stdio file descriptors as O_CLOEXEC before we spawn "runc init". For libcontainer library users, this could result in unrelated files being marked as O_CLOEXEC -- however (for the same reason we are doing this for runc), for security reasons those files should've been marked as O_CLOEXEC anyway. |
Aleksa Sarai <cyphar@cyphar.com> | no | 2023-12-28 | ||
| CVE-2024-21626/0024-init-don-t-special-case-logrus-fds.patch | init: don't special-case logrus fds We close the logfd before execve so there's no need to special case it. In addition, it turns out that (*os.File).Fd() doesn't handle the case where the file was closed and so it seems suspect to use that kind of check. |
Aleksa Sarai <cyphar@cyphar.com> | no | 2024-01-20 | ||
| 0025-Fix-busybox-tarball-url-in-integration-test.patch | Fix busybox tarball url in integration test https://github.com/opencontainers/runc/blob/main/tests/integration/get-images.sh |
Shengjing Zhu <zhsj@debian.org> | no | 2024-02-03 | ||
| CVE-2021-43784.patch | Fix CVE-2021-43784 When writing netlink messages, it is possible to have a byte array larger than UINT16_MAX which would result in the length field overflowing and allowing user-controlled data to be parsed as control characters (such as creating custom mount points, changing which set of namespaces to allow, and so on). |
Kir Kolyshkin <kolyshkin@gmail.com> | not-needed | upstream | https://github.com/opencontainers/runc/commit/d72d057ba794164c3cce9451a00b72a78b25e1ae | 2024-02-18 |
| 0027-Fix-test-for-newer-kernels.patch | [PATCH] tests/int/no_pivot: fix for new kernels The test is failing like this: not ok 70 runc run --no-pivot must not expose bare /proc # (in test file tests/integration/no_pivot.bats, line 20) # `[[ "$output" == *"mount: permission denied"* ]]' failed # runc spec (status=0): # # runc run --no-pivot test_no_pivot (status=1): # unshare: write error: Operation not permitted Apparently, a recent kernel commit db2e718a47984b9d prevents root from doing unshare -r unless it has CAP_SETFPCAP. Add the capability for this specific test. |
Kir Kolyshkin <kolyshkin@gmail.com> | not-needed | https://github.com/opencontainers/runc/commit/1bbeadae72603c44932d46ade275219dbf718950.patch | 2021-06-29 | |
| CVE-2023-25809.patch | [PATCH] rootless: fix /sys/fs/cgroup mounts It was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when runc is executed inside the user namespace, and the config.json does not specify the cgroup namespace to be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) 2. or, when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc spec --rootless`; this condition is very rare) A container may gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host. Other users's cgroup hierarchies are not affected. To fix the issue, this commit does: 1. Remount `/sys/fs/cgroup` to apply `MS_RDONLY` when it is being bind-mounted 2. Mask `/sys/fs/cgroup` when the bind source is unavailable Fix CVE-2023-25809 (GHSA-m8cg-xc2p-r3fc) (cherry picked from commit df4eae457b8ccffa619c659c2def5c777d8ff507) |
Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp> | not-needed | upstream | https://github.com/opencontainers/runc/commit/0e6b818a2b0d24fdb6697614e5c5f115bbe8e3a5.patch | 2022-12-26 |
| CVE-2023-27561-and-CVE-2023-28642.patch | [PATCH] Prohibit /proc and /sys to be symlinks Commit 3291d66b9844 introduced a check for /proc and /sys, making sure the destination (dest) is a directory (and not e.g. a symlink). Later, a hunk from commit 0ca91f44f switched from using filepath.Join to SecureJoin for dest. As SecureJoin follows and resolves symlinks, the check whether dest is a symlink no longer works. To fix, do the check without/before using SecureJoin. Add integration tests to make sure we won't regress. (cherry picked from commit 0d72adf96dda1b687815bf89bb245b937a2f603c) This patch fixes both, CVE-2023-27561 and CVE-2023-28642 |
Kir Kolyshkin <kolyshkin@gmail.com> | not-needed | https://github.com/opencontainers/runc/commit/0abab45c9b97c113ff2cdc16f3a7388444c3fbec.patch | 2023-03-16 |