Previously, PluginInfo was called with task options as the primary
value, resulting in opts.BinaryName being omitted. Consequently, the
containerd-shim-runc-v2 fell back to the system's runc binary in the
PATH rather than the explicitly specified one. This change inverts the
option fallback by preferring runtime options over task options,
ensuring the correct binary is used for the PluginInfo request.
Closes: https://github.com/containerd/containerd/issues/11169
Signed-off-by: Jose Fernandez <josef@netflix.com>
Reviewed-by: Erikson Tung <etung@netflix.com>
This is the fifth patch release in the 1.2.z series of runc. It
primarily fixes an issue caused by an upstream systemd bug.
There was a regression in systemd v230 which made the way we define device
rule restrictions require a systemctl daemon-reload for our transient
units. This caused issues for workloads using NVIDIA GPUs. Workaround the
upstream regression by re-arranging how the unit properties are defined.
Dependency github.com/cyphar/filepath-securejoin is updated to v0.4.1,
to allow projects that vendor runc to bump it as well.
CI: fixed criu-dev compilation.
Dependency golang.org/x/net is updated to 0.33.0.
diff: opencontainers/runc@v1.2.4...v1.2.5
Signed-off-by: Austin Vazquez <macedonv@amazon.com>
Block the synchronization of registering NRI plugins during
CRI events to avoid the plugin ending up in an inconsistent
starting state after initial sync (missing pods, containers
or missed events for some pods or containers).
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
- go1.23.5 (released 2025-01-16) includes security fixes to the
crypto/x509 and net/http packages, as well as bug fixes to the compiler,
the runtime, and the net package. See the Go 1.23.5 milestone on our
issue tracker for details.
- go1.22.11 (released 2025-01-16) includes security fixes to the
crypto/x509 and net/http packages, as well as bug fixes to the runtime.
See the Go 1.22.11 milestone on our issue tracker for details.
Signed-off-by: Akhil Mohan <akhilerm@gmail.com>
This function has been moved to prevent an unintended dependency on CDI.
Signed-off-by: Derek McGowan <derek@mcg.dev>
(cherry picked from commit bdc847f1eb535a6728b6db3f2619d2a5ed0edbb9)
Signed-off-by: Derek McGowan <derek@mcg.dev>
The CDI device injection spec opt was mistakenly added to the OCI
package which brought in an unintended dependency on CDI and its
transitive dependencies.
Signed-off-by: Derek McGowan <derek@mcg.dev>
(cherry picked from commit e20f7f4a2425c005d85855abfd4556d7b4ccbf87)
Signed-off-by: Derek McGowan <derek@mcg.dev>
The cri image service init has a bug where, after getting FSPath
for snapshotter_i, it stores it under defaultSnapshotter instead
of snapshotter_i.
Also make a few other refactor:
1. Dedup the snapshotRoot loading for defaultSnapshotter
2. Remove some unnecessary logic in RuntimePlatforms for-loop
Signed-off-by: Jin Dong <djdongjin95@gmail.com>
This is the fourth patch release of the 1.2.z release branch of runc. It
includes a fix for a regression introduced in 1.2.0 related to the
default device list.
- Re-add tun/tap devices to built-in allowed devices lists.
In runc 1.2.0 we removed these devices from the default allow-list
(which were added seemingly by accident early in Docker's history) as
a precaution in order to try to reduce the attack surface of device
inodes available to most containers. At the time we thought
that the vast majority of users using tun/tap would already be
specifying what devices they need (such as by using --device with
Docker/Podman) as opposed to doing the mknod manually, and thus
there would've been no user-visible change.
Unfortunately, it seems that this regressed a noticeable number of
users (and not all higher-level tools provide easy ways to specify
devices to allow) and so this change needed to be reverted. Users
that do not need these devices are recommended to explicitly disable
them by adding deny rules in their container configuration.
diff: https://github.com/opencontainers/runc/compare/v1.2.3...v1.2.4
Signed-off-by: Akhil Mohan <akhilerm@gmail.com>
