| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Add-go.mod-file.patch | Add go.mod file Fix build issue with + github.com/godbus/dbus/v5 + github.com/coreos/go-systemd/v22 |
Shengjing Zhu <zhsj@debian.org> | no | 2020-05-17 | ||
| 0002-disable-runhcs-option-in-cri-config.patch | disable runhcs option in cri config | Shengjing Zhu <zhsj@debian.org> | no | 2020-05-19 | ||
| 0003-disable-windows-support-in-ctr-metric.patch | disable windows support in ctr metric | Shengjing Zhu <zhsj@debian.org> | no | 2020-09-16 | ||
| 0004-Add-cgo-tag-to-btrfs-plugin.patch | Add cgo tag to btrfs plugin | Shengjing Zhu <zhsj@debian.org> | no | backport, https://github.com/containerd/containerd/pull/4964 | 2021-01-23 | |
| 0005-backport-github.com-containerd-containerd-remotes.patch | =?utf-8?q?backport_github=2Ecom/containerd/containerd/remotes?= =?utf-8?q?=C2=AC?= For building docker.io 20.10 This whole directory is replaced by commit 02334356d0774a5b194e67b5f1383fd2485ea67a v1.5.0-beta.3 |
Shengjing Zhu <zhsj@debian.org> | not-needed | 2021-11-23 | ||
| 0006-backport-apparmor-handle-signal-mediation.patch | apparmor: handle signal mediation On newer kernels and systems, AppArmor will block sending signals in many scenarios by default resulting in strange behaviours (container programs cannot signal each other, or host processes like containerd cannot signal containers). The reason this happens only on some distributions (and is not a kernel regression) is that the kernel doesn't enforce signal mediation unless the profile contains signal rules. However because our profies #include the distribution-managed <abstractions/base>, some distributions added signal rules -- which results in AppArmor enforcing signal mediation and thus a regression. On these systems, containers cannot send and receive signals at all -- meaning they cannot signal each other and the container runtime cannot kill them either. This issue was fixed in Docker in 2018[1] but this code was copied before then and thus the patches weren't carried. It also contains a new fix for a more esoteric case[2]. Ideally this code should live in a project like "containerd/apparmor" so that Docker, libpod, and containerd can share it, but that's probably something to do separately. In addition, the copyright header is updated to reference that the code is copied from Docker (and thus was not written entirely by the containerd authors). [1]: https://github.com/docker/docker/pull/37831 [2]: https://github.com/docker/docker/pull/41337 |
Aleksa Sarai <cyphar@cyphar.com> | no | backport, https://github.com/containerd/containerd/pull/4467 | 2020-08-11 | |
| 0007-backport-runtime-ignore-file-already-closed-error.patch | runtime: ignore file-already-closed error if dead shim | Wei Fu <fuweid89@gmail.com> | no | backport, https://github.com/containerd/containerd/pull/5174 | 2021-03-12 | |
| 0008-Add-RPi1-RPi0-workaround.patch | Add RPi1/RPi0 workaround On the very popular Raspberry Pi 1 and Zero devices, the CPU is actually ARMv6, but the chip happens to support the feature bit the kernel uses to differentiate v6/v7, so it gets reported as "CPU architecture: 7" and thus fails to run many of the images that get pulled. To account for this very popular edge case, this also checks "model name" which on these chips will begin with "ARMv6-compatible" -- we could also check uname, but getCPUInfo is already handy, low overhead, and mirrors the code before this. |
Tianon Gravi <admwiggin@gmail.com> | no | backport, https://github.com/containerd/containerd/commit/2055e12953bb538228d8d9fe627fa545d7cf82be | 2020-09-04 | |
| 0009-CVE-2022-31030.patch | CVE-2022-31030 | Shengjing Zhu <zhsj@debian.org> | no | backport, https://github.com/containerd/containerd/commit/c1bcabb4 | 2022-06-07 | |
| 0010-CVE-2022-24769.patch | CVE-2022-24769 | Shengjing Zhu <zhsj@debian.org> | no | backport, https://github.com/containerd/containerd/commit/921cf570 | 2022-06-07 |