- go1.23.3 (released 2024-11-06) includes fixes to the linker, the
runtime, and the net/http, os, and syscall packages. See the
Go 1.23.3 milestone on our issue tracker for details.
- go1.22.9 (released 2024-11-06) includes fixes to the linker. See
the Go 1.22.9 milestone on our issue tracker for details
Signed-off-by: Akhil Mohan <akhilerm@gmail.com>
Uses the new github.com/containerd/errdefs/pkg module which is intended
to hold less stable utility functions separately from the stable
github.com/containerd/errdefs error types.
Includes temporary update to hcsshim until a release is cut there
Signed-off-by: Derek McGowan <derek@mcg.dev>
Core should not have a dependency on API types.
This was causing a transative dependency on grpc when importing the core
snapshots package.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
- https://github.com/golang/go/issues?q=milestone%3AGo1.23.1+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.23.0...go1.23.1
These minor releases include 3 security fixes following the security policy:
- go/parser: stack exhaustion in all Parse* functions
Calling any of the Parse functions on Go source code which contains
deeply nested literals can cause a panic due to stack exhaustion.
This is CVE-2024-34155 and Go issue https://go.dev/issue/69138.
- encoding/gob: stack exhaustion in Decoder.Decode
Calling Decoder.Decode on a message which contains deeply nested
structures can cause a panic due to stack exhaustion.
This is a follow-up to CVE-2022-30635.
Thanks to Md Sakib Anwar of The Ohio State University for reporting
this issue.
This is CVE-2024-34156 and Go issue https://go.dev/issue/69139.
- go/build/constraint: stack exhaustion in Parse
Calling Parse on a "// +build" build tag line with deeply nested
expressions can cause a panic due to stack exhaustion.
This is CVE-2024-34158 and Go issue https://go.dev/issue/69141.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.23.1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes fix for a symlink race on remove.
Updates 1.21 to 1.21.11 for runc install which also includes the
symlink fix.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Go 1.22.3 release includes bug fixes for the core net/http package.
Full release notes: https://go.dev/doc/devel/release#go1.22.minor
Signed-off-by: Austin Vazquez <macedonv@amazon.com>
Allow the api to stay at the same v1 go package name and keep using a
1.x version number. This indicates the API is still at 1.x and allows
sharing proto types with containerd 1.6 and 1.7 releases.
Signed-off-by: Derek McGowan <derek@mcg.dev>
/usr/sbin/runc is confined with "runc" profile[1] introduced in AppArmor
v4.0.0. This change breaks stopping of containers, because the profile
assigned to containers doesn't accept signals from the "runc" peer.
AppArmor >= v4.0.0 is currently part of Ubuntu Mantic (23.10) and later.
The issue is reproducible both with nerdctl and ctr clients. In the case
of ctr, the --apparmor-default-profile flag has to be specified,
otherwise the container processes would inherit the runc profile, which
behaves as unconfined, and so the subsequent runc process invoked to
stop it would be able to signal it.
Test commands:
root@cloudimg:~# nerdctl run -d --name foo nginx:latest
3d1e74bfe6e7b2912d9223050ae8a81a8f4b73de0846e6d9c956c1e411cdd95a
root@cloudimg:~# nerdctl stop foo
FATA[0000] 1 errors:
unknown error after kill: runc did not terminate successfully: exit status 1: unable to signal init: permission denied
: unknown
or
root@cloudimg:~# ctr pull docker.io/library/nginx:latest
...
root@cloudimg:~# ctr run -d --apparmor-default-profile ctr-default docker.io/library/nginx:latest foo
root@cloudimg:~# ctr task kill foo
ctr: unknown error after kill: runc did not terminate successfully: exit status 1: unable to signal init: permission denied
: unknown
Relevant syslog messages (with long lines wrapped):
Apr 23 22:03:12 cloudimg kernel: audit:
type=1400 audit(1713909792.064:262): apparmor="DENIED"
operation="signal" class="signal" profile="nerdctl-default"
pid=13483 comm="runc" requested_mask="receive"
denied_mask="receive" signal=quit peer="runc"
or
Apr 23 22:05:32 cloudimg kernel: audit:
type=1400 audit(1713909932.106:263): apparmor="DENIED"
operation="signal" class="signal" profile="ctr-default"
pid=13574 comm="runc" requested_mask="receive"
denied_mask="receive" signal=quit peer="runc"
This change extends the default profile with rules that allow receiving
signals from processes that run confined with either runc or crun
profile (crun[2] is an alternative OCI runtime that's also confined in
AppArmor >= v4.0.0, see [1]). It is backward compatible because the peer
value is a regular expression (AARE) so the referenced profile doesn't
have to exist for this profile to successfully compile and load.
[1] https://gitlab.com/apparmor/apparmor/-/commit/2594d936
[2] https://github.com/containers/crun
Signed-off-by: Tomáš Virtus <nechtom@gmail.com>
Fix containerd/nerdctl issue 2730
> [Rootless] `nerdctl rm` fails when AppArmor is loaded:
> `error="unknown error after kill: runc did not terminate successfully: exit status 1:
> unable to signal init: permission denied\n: unknown"`
Caused by:
> kernel: audit: type=1400 audit(1713840662.766:122): apparmor="DENIED" operation="signal" class="signal"
> profile="nerdctl-default" pid=366783 comm="runc" requested_mask="receive" denied_mask="receive" signal=kill
> peer="/usr/local/bin/rootlesskit"
The issue is known to happen on Ubuntu 23.10 and 24.04 LTS.
Doesn't seem to happen on Ubuntu 22.04 LTS.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
go1.21.9 (released 2024-04-03) includes a security fix to the net/http
package, as well as bug fixes to the linker, and the go/types and
net/http packages. See the Go 1.21.9 milestone for more details;
https://github.com/golang/go/issues?q=milestone%3AGo1.21.9+label%3ACherryPickApproved
These minor releases include 1 security fixes following the security policy:
- http2: close connections when receiving too many headers
Maintaining HPACK state requires that we parse and process all HEADERS
and CONTINUATION frames on a connection. When a request's headers exceed
MaxHeaderBytes, we don't allocate memory to store the excess headers but
we do parse them. This permits an attacker to cause an HTTP/2 endpoint
to read arbitrary amounts of header data, all associated with a request
which is going to be rejected. These headers can include Huffman-encoded
data which is significantly more expensive for the receiver to decode
than for an attacker to send.
Set a limit on the amount of excess header frames we will process before
closing a connection.
Thanks to Bartek Nowotarski (https://nowotarski.info/) for reporting this issue.
This is CVE-2023-45288 and Go issue https://go.dev/issue/65051.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.22.2
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.9+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.8...go1.21.9
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
NRI is still newer and mostly used by CRI plugin. Keep the package in
internal to allow for interfaces as the project matures.
Signed-off-by: Derek McGowan <derek@mcg.dev>
