Package Instance

containerd affected by a local privilege escalation via wide permissions on CRI directory
### Impact

An overly broad default permission vulnerability was found in containerd.

- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700
  - Allowed local users on the host to potentially access the metadata store and the content store
- `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700
  - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
- `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700

The directory paths may differ depending on the daemon configuration.
When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.

> [!NOTE]
>
> `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711.
> This is an expected behavior for supporting userns-remapped containers.

### Workarounds

The system administrator on the host can manually chmod the directories to not 
have group or world accessible permisisons:

```
chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim
```

An alternative mitigation would be to run containerd in [rootless mode](https://github.com/containerd/containerd/blob/main/docs/rootless.md).

### Credits

The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)

containerd has an integer overflow in User ID handling
### Impact
A bug was found in containerd where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user.

### Patches
This bug has been fixed in the following containerd versions: 

* 2.0.4 (Fixed in https://github.com/containerd/containerd/commit/1a43cb6a1035441f9aca8f5666a9b3ef9e70ab20)
* 1.7.27 (Fixed in https://github.com/containerd/containerd/commit/05044ec0a9a75232cad458027ca83437aae3f4da)
* 1.6.38 (Fixed in https://github.com/containerd/containerd/commit/cf158e884cfe4812a6c371b59e4ea9bc4c46e51a)

Users should update to these versions to resolve the issue.

### Workarounds
Ensure that only trusted images are used and that only trusted users have permissions to import images.

### Credits
The containerd project would like to thank [Benjamin Koltermann](https://github.com/p4ck3t0) and [emxll](https://github.com/emxll) for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### References
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-40635

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:
* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
* Email us at [security@containerd.io](mailto:security@containerd.io)

containerd CRI server: Host memory exhaustion through Attach goroutine leak
### Impact

A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. 

Repetitive calls of CRI Attach (e.g., [`kubectl attach`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_attach/)) could increase the memory usage of containerd.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.

### Workarounds

Set up an admission controller to control accesses to `pods/attach` resources.
e.g., [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).

### Credits

The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)

Supplementary groups are not set up properly in github.com/containerd/containerd
### Impact

A bug was found in containerd where supplementary groups are not set up properly inside a container.  If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.

Downstream applications that use the containerd client library may be affected as well.

### Patches
This bug has been fixed in containerd v1.6.18 and v.1.5.18.  Users should update to these versions and recreate containers to resolve this issue.  Users who rely on a downstream application that uses containerd's client library should check that application for a separate advisory and instructions.

### Workarounds

Ensure that the `"USER $USERNAME"` Dockerfile instruction is not used.  Instead, set the container entrypoint to a value similar to `ENTRYPOINT ["su", "-", "user"]` to allow `su` to properly set up supplementary groups.

### References

- https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/
- Docker/Moby: CVE-2022-36109, fixed in Docker 20.10.18
- CRI-O: CVE-2022-2995, fixed in CRI-O 1.25.0
- Podman: CVE-2022-2989, fixed in Podman 3.0.1 and 4.2.0
- Buildah: CVE-2022-2990, fixed in Buildah 1.27.1

Note that CVE IDs apply to a particular implementation, even if an issue is common.

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:
* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
* Email us at [security@containerd.io](mailto:security@containerd.io)

OCI image importer memory exhaustion in github.com/containerd/containerd
### Impact
When importing an OCI image, there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file where a limit was not applied could cause a denial of service.

### Patches

This bug has been fixed in containerd 1.6.18 and 1.5.18.  Users should update to these versions to resolve the issue.

### Workarounds

Ensure that only trusted images are used and that only trusted users have permissions to import images. 

### Credits

The containerd project would like to thank [David Korczynski](https://github.com/DavidKorczynski) and [Adam Korczynski](https://github.com/AdamKorcz) of ADA Logics for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md) during a security fuzzing audit sponsored by CNCF.

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:
* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
* Email us at [security@containerd.io](mailto:security@containerd.io)