| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-skip-test-hugetlb_test.go.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-factory_linux_test.go.patch | skip privileged test: factory_linux_test.go | Dmitry Smirnov <onlyjob@debian.org> | not-needed | 2018-06-15 | ||
| 0003-skip-privileged-test-nsenter_test.go.patch | skip privileged test: nsenter_test.go | Shengjing Zhu <zhsj@debian.org> | no | 2021-01-23 | ||
| 0004-skip-test-cgroups_test.go.patch | skip test: cgroups_test.go Fail when cgroups is not mounted |
Shengjing Zhu <zhsj@debian.org> | no | 2021-01-23 | ||
| 0005-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 | ||
| 0006-skip-test-paths_test.go.patch | skip test: paths_test.go Fail when cgroups is not mounted |
Shengjing Zhu <zhsj@debian.org> | no | 2021-12-15 | ||
| 0007-skip-test-manager_test.go.patch | skip test: manager_test.go Fail when cgroups is not mounted |
Shengjing Zhu <zhsj@debian.org> | no | 2021-12-15 | ||
| 0008-tests-enable-seccomp-default-action-tests-on-arm.patch | tests: enable seccomp default action tests on arm | Shengjing Zhu <zhsj@debian.org> | yes | 2022-06-20 | ||
| 0009-skip-test-file_test.go.patch | skip test: file_test.go Fail when cgroups is not mounted |
Shengjing Zhu <zhsj@debian.org> | no | 2023-03-29 | ||
| 0010-export-blockIODevice.patch | export blockIODevice the struct blockIODevice is used in an exported struct but it is not itself exported rendering that type inaccessible to outside projects |
cdoern <cdoern@redhat.com> | no | 2022-08-27 | ||
| CVE-2024-21626/0011-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/0012-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/0013-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/0014-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/0015-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/0016-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/0017-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 | ||
| CVE-2024-21626/0018-Adapt-eaccess-check-for-runc-1.1.6.patch | Adapt eaccess check for runc < 1.1.6 The check is same in libcontainer/standard_init_linux.go |
Shengjing Zhu <zhsj@debian.org> | no | 2024-02-02 |