Update vulnerable dependencies [SECURITY] (#671)
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [github.com/containerd/containerd/v2](https://redirect.github.com/containerd/containerd) | indirect | patch | `v2.0.3` -> `v2.0.7` | | [github.com/go-viper/mapstructure/v2](https://redirect.github.com/go-viper/mapstructure) | indirect | minor | `v2.0.0` -> `v2.4.0` | | [github.com/ulikunitz/xz](https://redirect.github.com/ulikunitz/xz) | indirect | patch | `v0.5.12` -> `v0.5.15` | | golang.org/x/crypto | indirect | minor | `v0.39.0` -> `v0.45.0` | ### GitHub Vulnerability Alerts #### [CVE-2024-40635](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-265r-hfxg-fhmg) ### 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 in1a43cb6a10) * 1.7.27 (Fixed in05044ec0a9) * 1.6.38 (Fixed incf158e884c) 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://redirect.github.com/p4ck3t0) and [emxll](https://redirect.github.com/emxll) for responsibly disclosing this issue in accordance with the [containerd security policy](https://redirect.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://redirect.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://redirect.github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) #### [CVE-2025-47291](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-cxfp-7pvr-95ff) # Impact A bug was found in the containerd's CRI implementation where containerd doesn't put usernamespaced containers under the Kubernetes' cgroup hierarchy, therefore some Kubernetes limits are not honored. This may cause a denial of service of the Kubernetes node. # Patches This bug has been fixed in containerd 2.0.5+ and 2.1.0+. Users should update to these versions to resolve the issue. # Workarounds Disable usernamespaced pods in Kubernetes temporarily. # Credits The containerd project would like to thank Rodrigo Campos Catelin and Piotr Rogowski for responsibly disclosing this issue in accordance with the [containerd security policy](https://redirect.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://redirect.github.com/containerd/containerd/issues/new/choose) * Email us at security@containerd.io To report a security issue in containerd: * [Report a new vulnerability](https://redirect.github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) #### [CVE-2024-25621](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-pwhc-rpq9-4c8w) ### 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://redirect.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://redirect.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://redirect.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://redirect.github.com/containerd/containerd/security/advisories/new) #### [CVE-2025-64329](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-m6hq-p25p-ffr2) ### 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://redirect.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://redirect.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://redirect.github.com/containerd/containerd/security/advisories/new) --- ### containerd has an integer overflow in User ID handling in github.com/containerd/containerd [CVE-2024-40635](https://nvd.nist.gov/vuln/detail/CVE-2024-40635) / [GHSA-265r-hfxg-fhmg](https://redirect.github.com/advisories/GHSA-265r-hfxg-fhmg) / [GO-2025-3528](https://pkg.go.dev/vuln/GO-2025-3528) <details> <summary>More information</summary> #### Details containerd has an integer overflow in User ID handling in github.com/containerd/containerd #### Severity Unknown #### References - [https://github.com/containerd/containerd/security/advisories/GHSA-265r-hfxg-fhmg](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-265r-hfxg-fhmg) - [05044ec0a9) - [1a43cb6a10) - [cf158e884c) This data is provided by [OSV](https://osv.dev/vulnerability/GO-2025-3528) and the [Go Vulnerability Database](https://redirect.github.com/golang/vulndb) ([CC-BY 4.0](https://redirect.github.com/golang/vulndb#license)). </details> --- ### containerd has an integer overflow in User ID handling [CVE-2024-40635](https://nvd.nist.gov/vuln/detail/CVE-2024-40635) / [GHSA-265r-hfxg-fhmg](https://redirect.github.com/advisories/GHSA-265r-hfxg-fhmg) / [GO-2025-3528](https://pkg.go.dev/vuln/GO-2025-3528) <details> <summary>More information</summary> #### Details ##### 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 in1a43cb6a10) * 1.7.27 (Fixed in05044ec0a9) * 1.6.38 (Fixed incf158e884c) 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://redirect.github.com/p4ck3t0) and [emxll](https://redirect.github.com/emxll) for responsibly disclosing this issue in accordance with the [containerd security policy](https://redirect.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://redirect.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://redirect.github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) #### Severity - CVSS Score: 4.6 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N` #### References - [https://github.com/containerd/containerd/security/advisories/GHSA-265r-hfxg-fhmg](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-265r-hfxg-fhmg) - [https://nvd.nist.gov/vuln/detail/CVE-2024-40635](https://nvd.nist.gov/vuln/detail/CVE-2024-40635) - [05044ec0a9) - [1a43cb6a10) - [cf158e884c) - [https://github.com/containerd/containerd](https://redirect.github.com/containerd/containerd) - [https://lists.debian.org/debian-lts-announce/2025/05/msg00005.html](https://lists.debian.org/debian-lts-announce/2025/05/msg00005.html) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-265r-hfxg-fhmg) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### containerd CRI plugin: Incorrect cgroup hierarchy assignment for containers running in usernamespaced Kubernetes pods. [CVE-2025-47291](https://nvd.nist.gov/vuln/detail/CVE-2025-47291) / [GHSA-cxfp-7pvr-95ff](https://redirect.github.com/advisories/GHSA-cxfp-7pvr-95ff) / [GO-2025-3701](https://pkg.go.dev/vuln/GO-2025-3701) <details> <summary>More information</summary> #### Details ##### Impact A bug was found in the containerd's CRI implementation where containerd doesn't put usernamespaced containers under the Kubernetes' cgroup hierarchy, therefore some Kubernetes limits are not honored. This may cause a denial of service of the Kubernetes node. ##### Patches This bug has been fixed in containerd 2.0.5+ and 2.1.0+. Users should update to these versions to resolve the issue. ##### Workarounds Disable usernamespaced pods in Kubernetes temporarily. ##### Credits The containerd project would like to thank Rodrigo Campos Catelin and Piotr Rogowski for responsibly disclosing this issue in accordance with the [containerd security policy](https://redirect.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://redirect.github.com/containerd/containerd/issues/new/choose) * Email us at security@containerd.io To report a security issue in containerd: * [Report a new vulnerability](https://redirect.github.com/containerd/containerd/security/advisories/new) * Email us at [security@containerd.io](mailto:security@containerd.io) #### Severity - CVSS Score: Unknown - Vector String: `CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U` #### References - [https://github.com/containerd/containerd/security/advisories/GHSA-cxfp-7pvr-95ff](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-cxfp-7pvr-95ff) - [https://nvd.nist.gov/vuln/detail/CVE-2025-47291](https://nvd.nist.gov/vuln/detail/CVE-2025-47291) - [https://github.com/containerd/containerd](https://redirect.github.com/containerd/containerd) - [https://pkg.go.dev/vuln/GO-2025-3701](https://pkg.go.dev/vuln/GO-2025-3701) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-cxfp-7pvr-95ff) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Incorrect cgroup assignment for containers running in usernamespaced Kubernetes pods in github.com/containerd/containerd [CVE-2025-47291](https://nvd.nist.gov/vuln/detail/CVE-2025-47291) / [GHSA-cxfp-7pvr-95ff](https://redirect.github.com/advisories/GHSA-cxfp-7pvr-95ff) / [GO-2025-3701](https://pkg.go.dev/vuln/GO-2025-3701) <details> <summary>More information</summary> #### Details Incorrect cgroup assignment for containers running in usernamespaced Kubernetes pods in github.com/containerd/containerd #### Severity Unknown #### References - [https://github.com/containerd/containerd/security/advisories/GHSA-cxfp-7pvr-95ff](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-cxfp-7pvr-95ff) This data is provided by [OSV](https://osv.dev/vulnerability/GO-2025-3701) and the [Go Vulnerability Database](https://redirect.github.com/golang/vulndb) ([CC-BY 4.0](https://redirect.github.com/golang/vulndb#license)). </details> --- ### containerd affected by a local privilege escalation via wide permissions on CRI directory [CVE-2024-25621](https://nvd.nist.gov/vuln/detail/CVE-2024-25621) / [GHSA-pwhc-rpq9-4c8w](https://redirect.github.com/advisories/GHSA-pwhc-rpq9-4c8w) <details> <summary>More information</summary> #### Details ##### 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://redirect.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://redirect.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://redirect.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://redirect.github.com/containerd/containerd/security/advisories/new) #### Severity - CVSS Score: 7.3 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H` #### References - [https://github.com/containerd/containerd/security/advisories/GHSA-pwhc-rpq9-4c8w](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-pwhc-rpq9-4c8w) - [https://nvd.nist.gov/vuln/detail/CVE-2024-25621](https://nvd.nist.gov/vuln/detail/CVE-2024-25621) - [7c59e8e9e9) - [https://github.com/containerd/containerd](https://redirect.github.com/containerd/containerd) - [https://github.com/containerd/containerd/blob/main/docs/rootless.md](https://redirect.github.com/containerd/containerd/blob/main/docs/rootless.md) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-pwhc-rpq9-4c8w) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### containerd CRI server: Host memory exhaustion through Attach goroutine leak [CVE-2025-64329](https://nvd.nist.gov/vuln/detail/CVE-2025-64329) / [GHSA-m6hq-p25p-ffr2](https://redirect.github.com/advisories/GHSA-m6hq-p25p-ffr2) <details> <summary>More information</summary> #### Details ##### 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://redirect.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://redirect.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://redirect.github.com/containerd/containerd/security/advisories/new) #### Severity - CVSS Score: Unknown - Vector String: `CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N` #### References - [https://github.com/containerd/containerd/security/advisories/GHSA-m6hq-p25p-ffr2](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-m6hq-p25p-ffr2) - [https://nvd.nist.gov/vuln/detail/CVE-2025-64329](https://nvd.nist.gov/vuln/detail/CVE-2025-64329) - [083b53cd6f) - [https://github.com/containerd/containerd](https://redirect.github.com/containerd/containerd) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-m6hq-p25p-ffr2) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> #### [GHSA-fv92-fjc5-jj9h](https://redirect.github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h) ### Summary Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields. ### Details OpenBao (and presumably HashiCorp Vault) have surfaced error messages from `mapstructure` as follows:98c3a59c04/sdk/framework/field_data.go (L43-L50)```go _, _, err := d.getPrimitive(field, schema) if err != nil { return fmt.Errorf("error converting input for field %q: %w", field, err) } ``` where this calls `mapstructure.WeakDecode(...)`:98c3a59c04/sdk/framework/field_data.go (L181-L193)```go func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) { raw, ok := d.Raw[k] if !ok { return nil, false, nil } switch t := schema.Type; t { case TypeBool: var result bool if err := mapstructure.WeakDecode(raw, &result); err != nil { return nil, false, err } return result, true, nil ``` Notably, `WeakDecode(...)` eventually calls one of the decode helpers, which surfaces the original value:1a66224d5e/mapstructure.go (L679-L686)1a66224d5e/mapstructure.go (L726-L730)1a66224d5e/mapstructure.go (L783-L787)& more. ### PoC To reproduce with OpenBao: ``` $ podman run -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300 ``` and in a new tab: ``` $ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass Success! Enabled userpass auth method at: userpass/ $ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"password":{"asdf":"my-sensitive-value"}}' "http://localhost:8300/v1/auth/userpass/users/adsf" {"errors":["error converting input for field \"password\": '' expected type 'string', got unconvertible type 'map[string]interface {}', value: 'map[asdf:my-sensitive-value]'"]} ``` ### Impact This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at `'' expected a map, got 'string'` -- when the field type is `string` and a `map` is provided, we see the above information leak -- the previous example had a `map` type field with a `string` value provided). This was rated 4.5 Medium by HashiCorp in the past iteration. #### [GHSA-2464-8j7c-4cjm](https://redirect.github.com/go-viper/mapstructure/security/advisories/GHSA-2464-8j7c-4cjm) ### Summary Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields. ### Details OpenBao (and presumably HashiCorp Vault) have surfaced error messages from `mapstructure` as follows:98c3a59c04/sdk/framework/field_data.go (L43-L50)```go _, _, err := d.getPrimitive(field, schema) if err != nil { return fmt.Errorf("error converting input for field %q: %w", field, err) } ``` where this calls `mapstructure.WeakDecode(...)`:98c3a59c04/sdk/framework/field_data.go (L181-L193)```go func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) { raw, ok := d.Raw[k] if !ok { return nil, false, nil } switch t := schema.Type; t { case TypeBool: var result bool if err := mapstructure.WeakDecode(raw, &result); err != nil { return nil, false, err } return result, true, nil ``` Notably, `WeakDecode(...)` eventually calls one of the decode helpers, which surfaces the original value via `strconv` helpers:8c61ec1924/mapstructure.go (L720-L727)8c61ec1924/mapstructure.go (L791-L798)8c61ec1924/decode_hooks.go (L180)& more. These are different code paths than are fixed in the previous iteration at https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h. ### PoC To reproduce with OpenBao: ``` $ podman run --pull=always -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300 ``` and in a new tab: ``` $ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass Success! Enabled userpass auth method at: userpass/ $ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"ttl":"asdf"}' "http://localhost:8200/v1/auth/userpass/users/asdf" --> server logs: 2025-06-25T21:32:25.101-0500 [ERROR] core: failed to run existence check: error="error converting input for field \"ttl\": time: invalid duration \"asdf\"" ``` ### Impact This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at `'' expected a map, got 'string'` -- when the field type is `string` and a `map` is provided, we see the above information leak -- the previous example had a `map` type field with a `string` value provided). This was rated 4.5 Medium by HashiCorp in the past iteration. --- ### mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data [GHSA-fv92-fjc5-jj9h](https://redirect.github.com/advisories/GHSA-fv92-fjc5-jj9h) / [GO-2025-3787](https://pkg.go.dev/vuln/GO-2025-3787) <details> <summary>More information</summary> #### Details ##### Summary Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields. ##### Details OpenBao (and presumably HashiCorp Vault) have surfaced error messages from `mapstructure` as follows:98c3a59c04/sdk/framework/field_data.go (L43-L50)```go _, _, err := d.getPrimitive(field, schema) if err != nil { return fmt.Errorf("error converting input for field %q: %w", field, err) } ``` where this calls `mapstructure.WeakDecode(...)`:98c3a59c04/sdk/framework/field_data.go (L181-L193)```go func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) { raw, ok := d.Raw[k] if !ok { return nil, false, nil } switch t := schema.Type; t { case TypeBool: var result bool if err := mapstructure.WeakDecode(raw, &result); err != nil { return nil, false, err } return result, true, nil ``` Notably, `WeakDecode(...)` eventually calls one of the decode helpers, which surfaces the original value:1a66224d5e/mapstructure.go (L679-L686)1a66224d5e/mapstructure.go (L726-L730)1a66224d5e/mapstructure.go (L783-L787)& more. ##### PoC To reproduce with OpenBao: ``` $ podman run -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300 ``` and in a new tab: ``` $ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass Success! Enabled userpass auth method at: userpass/ $ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"password":{"asdf":"my-sensitive-value"}}' "http://localhost:8300/v1/auth/userpass/users/adsf" {"errors":["error converting input for field \"password\": '' expected type 'string', got unconvertible type 'map[string]interface {}', value: 'map[asdf:my-sensitive-value]'"]} ``` ##### Impact This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at `'' expected a map, got 'string'` -- when the field type is `string` and a `map` is provided, we see the above information leak -- the previous example had a `map` type field with a `string` value provided). This was rated 4.5 Medium by HashiCorp in the past iteration. #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N` #### References - [https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h](https://redirect.github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h) - [https://github.com/go-viper/mapstructure](https://redirect.github.com/go-viper/mapstructure) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-fv92-fjc5-jj9h) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### May leak sensitive information in logs when processing malformed data in github.com/go-viper/mapstructure [GHSA-fv92-fjc5-jj9h](https://redirect.github.com/advisories/GHSA-fv92-fjc5-jj9h) / [GO-2025-3787](https://pkg.go.dev/vuln/GO-2025-3787) <details> <summary>More information</summary> #### Details May leak sensitive information in logs when processing malformed data in github.com/go-viper/mapstructure #### Severity Unknown #### References - [https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h](https://redirect.github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h) This data is provided by [OSV](https://osv.dev/vulnerability/GO-2025-3787) and the [Go Vulnerability Database](https://redirect.github.com/golang/vulndb) ([CC-BY 4.0](https://redirect.github.com/golang/vulndb#license)). </details> --- ### Go-viper's mapstructure May Leak Sensitive Information in Logs in github.com/go-viper/mapstructure [GHSA-2464-8j7c-4cjm](https://redirect.github.com/advisories/GHSA-2464-8j7c-4cjm) / [GO-2025-3900](https://pkg.go.dev/vuln/GO-2025-3900) <details> <summary>More information</summary> #### Details Go-viper's mapstructure May Leak Sensitive Information in Logs in github.com/go-viper/mapstructure #### Severity Unknown #### References - [https://github.com/go-viper/mapstructure/security/advisories/GHSA-2464-8j7c-4cjm](https://redirect.github.com/go-viper/mapstructure/security/advisories/GHSA-2464-8j7c-4cjm) - [742921c9ba) This data is provided by [OSV](https://osv.dev/vulnerability/GO-2025-3900) and the [Go Vulnerability Database](https://redirect.github.com/golang/vulndb) ([CC-BY 4.0](https://redirect.github.com/golang/vulndb#license)). </details> --- ### go-viper's mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data [GHSA-2464-8j7c-4cjm](https://redirect.github.com/advisories/GHSA-2464-8j7c-4cjm) / [GO-2025-3900](https://pkg.go.dev/vuln/GO-2025-3900) <details> <summary>More information</summary> #### Details ##### Summary Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields. ##### Details OpenBao (and presumably HashiCorp Vault) have surfaced error messages from `mapstructure` as follows:98c3a59c04/sdk/framework/field_data.go (L43-L50)```go _, _, err := d.getPrimitive(field, schema) if err != nil { return fmt.Errorf("error converting input for field %q: %w", field, err) } ``` where this calls `mapstructure.WeakDecode(...)`:98c3a59c04/sdk/framework/field_data.go (L181-L193)```go func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) { raw, ok := d.Raw[k] if !ok { return nil, false, nil } switch t := schema.Type; t { case TypeBool: var result bool if err := mapstructure.WeakDecode(raw, &result); err != nil { return nil, false, err } return result, true, nil ``` Notably, `WeakDecode(...)` eventually calls one of the decode helpers, which surfaces the original value via `strconv` helpers:8c61ec1924/mapstructure.go (L720-L727)8c61ec1924/mapstructure.go (L791-L798)8c61ec1924/decode_hooks.go (L180)& more. These are different code paths than are fixed in the previous iteration at https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h. ##### PoC To reproduce with OpenBao: ``` $ podman run --pull=always -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300 ``` and in a new tab: ``` $ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass Success! Enabled userpass auth method at: userpass/ $ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"ttl":"asdf"}' "http://localhost:8200/v1/auth/userpass/users/asdf" --> server logs: 2025-06-25T21:32:25.101-0500 [ERROR] core: failed to run existence check: error="error converting input for field \"ttl\": time: invalid duration \"asdf\"" ``` ##### Impact This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at `'' expected a map, got 'string'` -- when the field type is `string` and a `map` is provided, we see the above information leak -- the previous example had a `map` type field with a `string` value provided). This was rated 4.5 Medium by HashiCorp in the past iteration. #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N` #### References - [https://github.com/go-viper/mapstructure/security/advisories/GHSA-2464-8j7c-4cjm](https://redirect.github.com/go-viper/mapstructure/security/advisories/GHSA-2464-8j7c-4cjm) - [742921c9ba) - [https://github.com/go-viper/mapstructure](https://redirect.github.com/go-viper/mapstructure) - [https://pkg.go.dev/vuln/GO-2025-3900](https://pkg.go.dev/vuln/GO-2025-3900) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-2464-8j7c-4cjm) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> #### [CVE-2025-58058](https://redirect.github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9) ### Summary It is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the [specification](https://redirect.github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt). Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. ### Mitigations The release v0.5.15 includes following mitigations: - The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size. - The default is 2 Gigabytes - 1 byte (2^31-1 bytes). - Users can check with the [Reader.Header] method what the actual values are in their LZMA files and set a smaller limit using ReaderConfig. - The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary. - The code supports stream sizes only up to a pebibyte (1024^5). Note that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15. ### Methods affected Only software that uses [lzma.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#NewReader) or [lzma.ReaderConfig.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#ReaderConfig.NewReader) is affected. There is no issue for software using the xz functionality. I thank @​GregoryBuligin for his report, which is provided below. ### Summary When unpacking a large number of LZMA archives, even in a single goroutine, if the first byte of the archive file is 0 (a zero byte added to the beginning), an error __writeMatch: distance out of range__ occurs. Memory consumption spikes sharply, and the GC clearly cannot handle this situation. ### Details Judging by the error __writeMatch: distance out of range__, the problems occur in the code around this function.c8314b8f21/lzma/decoderdict.go (L81)### PoC Run a function similar to this one in 1 or several goroutines on a multitude of LZMA archives that have a 0 (a zero byte) added to the beginning. ``` const ProjectLocalPath = "some/path" const TmpDir = "tmp" func UnpackLZMA(lzmaFile string) error { file, err := os.Open(lzmaFile) if err != nil { return err } defer file.Close() reader, err := lzma.NewReader(bufio.NewReader(file)) if err != nil { return err } tmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix) if err != nil { return err } defer func() { tmpFile.Close() _ = os.Remove(tmpFile.Name()) }() sha256Hasher := sha256.New() multiWriter := io.MultiWriter(tmpFile, sha256Hasher) if _, err = io.Copy(multiWriter, reader); err != nil { return err } unpackHash := hex.EncodeToString(sha256Hasher.Sum(nil)) unpackDir := filepath.Join( ProjectLocalPath, unpackHash[:2], ) _ = os.MkdirAll(unpackDir, DirPerm) unpackPath := filepath.Join(unpackDir, unpackHash) return os.Rename(tmpFile.Name(), unpackPath) } ``` ### Impact Servers with a small amount of RAM that download and unpack a large number of unverified LZMA archives --- ### github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives [CVE-2025-58058](https://nvd.nist.gov/vuln/detail/CVE-2025-58058) / [GHSA-jc7w-c686-c4v9](https://redirect.github.com/advisories/GHSA-jc7w-c686-c4v9) / [GO-2025-3922](https://pkg.go.dev/vuln/GO-2025-3922) <details> <summary>More information</summary> #### Details ##### Summary It is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the [specification](https://redirect.github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt). Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. ##### Mitigations The release v0.5.15 includes following mitigations: - The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size. - The default is 2 Gigabytes - 1 byte (2^31-1 bytes). - Users can check with the [Reader.Header] method what the actual values are in their LZMA files and set a smaller limit using ReaderConfig. - The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary. - The code supports stream sizes only up to a pebibyte (1024^5). Note that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15. ##### Methods affected Only software that uses [lzma.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#NewReader) or [lzma.ReaderConfig.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#ReaderConfig.NewReader) is affected. There is no issue for software using the xz functionality. I thank @​GregoryBuligin for his report, which is provided below. ##### Summary When unpacking a large number of LZMA archives, even in a single goroutine, if the first byte of the archive file is 0 (a zero byte added to the beginning), an error __writeMatch: distance out of range__ occurs. Memory consumption spikes sharply, and the GC clearly cannot handle this situation. ##### Details Judging by the error __writeMatch: distance out of range__, the problems occur in the code around this function.c8314b8f21/lzma/decoderdict.go (L81)##### PoC Run a function similar to this one in 1 or several goroutines on a multitude of LZMA archives that have a 0 (a zero byte) added to the beginning. ``` const ProjectLocalPath = "some/path" const TmpDir = "tmp" func UnpackLZMA(lzmaFile string) error { file, err := os.Open(lzmaFile) if err != nil { return err } defer file.Close() reader, err := lzma.NewReader(bufio.NewReader(file)) if err != nil { return err } tmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix) if err != nil { return err } defer func() { tmpFile.Close() _ = os.Remove(tmpFile.Name()) }() sha256Hasher := sha256.New() multiWriter := io.MultiWriter(tmpFile, sha256Hasher) if _, err = io.Copy(multiWriter, reader); err != nil { return err } unpackHash := hex.EncodeToString(sha256Hasher.Sum(nil)) unpackDir := filepath.Join( ProjectLocalPath, unpackHash[:2], ) _ = os.MkdirAll(unpackDir, DirPerm) unpackPath := filepath.Join(unpackDir, unpackHash) return os.Rename(tmpFile.Name(), unpackPath) } ``` ##### Impact Servers with a small amount of RAM that download and unpack a large number of unverified LZMA archives #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L` #### References - [https://github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9](https://redirect.github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9) - [https://nvd.nist.gov/vuln/detail/CVE-2025-58058](https://nvd.nist.gov/vuln/detail/CVE-2025-58058) - [88ddf1d0d9) - [https://github.com/ulikunitz/xz](https://redirect.github.com/ulikunitz/xz) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-jc7w-c686-c4v9) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### Memory leaks when decoding a corrupted multiple LZMA archives in github.com/ulikunitz/xz [CVE-2025-58058](https://nvd.nist.gov/vuln/detail/CVE-2025-58058) / [GHSA-jc7w-c686-c4v9](https://redirect.github.com/advisories/GHSA-jc7w-c686-c4v9) / [GO-2025-3922](https://pkg.go.dev/vuln/GO-2025-3922) <details> <summary>More information</summary> #### Details Memory leaks when decoding a corrupted multiple LZMA archives in github.com/ulikunitz/xz #### Severity Unknown #### References - [https://github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9](https://redirect.github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9) - [88ddf1d0d9) This data is provided by [OSV](https://osv.dev/vulnerability/GO-2025-3922) and the [Go Vulnerability Database](https://redirect.github.com/golang/vulndb) ([CC-BY 4.0](https://redirect.github.com/golang/vulndb#license)). </details> #### [CVE-2025-58181](https://nvd.nist.gov/vuln/detail/CVE-2025-58181) SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption. #### [CVE-2025-47914](https://nvd.nist.gov/vuln/detail/CVE-2025-47914) SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read. --- ### Release Notes <details> <summary>containerd/containerd (github.com/containerd/containerd/v2)</summary> ### [`v2.0.7`](https://redirect.github.com/containerd/containerd/releases/tag/v2.0.7): containerd 2.0.7 [Compare Source](https://redirect.github.com/containerd/containerd/compare/v2.0.6...v2.0.7) Welcome to the v2.0.7 release of containerd! The seventh patch release for containerd 2.0 includes various bug fixes and updates. ##### Security Updates - **containerd** - [**GHSA-pwhc-rpq9-4c8w**](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-pwhc-rpq9-4c8w) - [**GHSA-m6hq-p25p-ffr2**](https://redirect.github.com/containerd/containerd/security/advisories/GHSA-m6hq-p25p-ffr2) - **runc** - [**GHSA-qw9x-cqr3-wc7r**](https://redirect.github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r) - [**GHSA-cgrx-mc8f-2prm**](https://redirect.github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm) - [**GHSA-9493-h29p-rfm2**](https://redirect.github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2) ##### Highlights ##### Container Runtime Interface (CRI) - **Disable event subscriber during task cleanup** ([#​12406](https://redirect.github.com/containerd/containerd/pull/12406)) - **Add SystemdCgroup to default runtime options** ([#​12254](https://redirect.github.com/containerd/containerd/pull/12254)) - **Fix userns with container image VOLUME mounts that need copy** ([#​12241](https://redirect.github.com/containerd/containerd/pull/12241)) ##### Image Distribution - **Add dial timeout field to hosts toml configuration** ([#​12136](https://redirect.github.com/containerd/containerd/pull/12136)) ##### Runtime - **Update runc binary to v1.3.3** ([#​12479](https://redirect.github.com/containerd/containerd/pull/12479)) - **Fix lost container logs from quickly closing io** ([#​12376](https://redirect.github.com/containerd/containerd/pull/12376)) - **Create bootstrap.json with 0644 permission** ([#​12184](https://redirect.github.com/containerd/containerd/pull/12184)) - **Fix pidfd leak in UnshareAfterEnterUserns** ([#​12178](https://redirect.github.com/containerd/containerd/pull/12178)) Please try out the release binaries and report any issues at https://github.com/containerd/containerd/issues. ##### Contributors - Austin Vazquez - Phil Estes - Rodrigo Campos - Wei Fu - Akihiro Suda - Derek McGowan - Maksym Pavlenko - ningmingxiao - Kirtana Ashok - Akhil Mohan - Andrew Halaney - Jin Dong - Jose Fernandez - Mike Baynton - Philip Laine - Swagat Bora - wheat2018 ##### Changes <details><summary>56 commits</summary> <p> - Prepare release notes for v2.0.7 ([#​12482](https://redirect.github.com/containerd/containerd/pull/12482)) - [`4931e24f1`](4931e24f16) Prepare release notes for v2.0.7 - [`205bc4f2d`](205bc4f2db) Update mailmap - [`5f708b76a`](5f708b76a4) Merge commit from fork - [`8cd112d82`](8cd112d829) Fix directory permissions - [`05290b5bc`](05290b5bc8) Merge commit from fork - [`4d1edf4ad`](4d1edf4add) fix goroutine leak of container Attach - Update runc binary to v1.3.3 ([#​12479](https://redirect.github.com/containerd/containerd/pull/12479)) - [`b46dc6a67`](b46dc6a67c) runc: Update runc binary to v1.3.3 - ci: bump Go 1.24.9; 1.25.3 ([#​12361](https://redirect.github.com/containerd/containerd/pull/12361)) - [`5e9c82178`](5e9c821780) Update GHA runners to use latest images for basic binaries build - [`7f59248dc`](7f59248dcd) Update GHA runners to use latest image for most jobs - [`e1373e8a8`](e1373e8a8a) ci: bump Go 1.24.9, 1.25.3 - [`e1a910a6a`](e1a910a6a9) ci: bump Go 1.24.8; 1.25.2 - [`fd04b7f17`](fd04b7f176) move exclude-dirs to issues.exclude-dirs - [`b49377975`](b493779751) update golangci-lint to v1.64.2 - [`6e45022a1`](6e45022a1e) build(deps): bump golangci/golangci-lint-action from 6.3.2 to 6.5.0 - [`09ce0f2a1`](09ce0f2a1e) build(deps): bump golangci/golangci-lint-action from 6.2.0 to 6.3.2 - [`de63a740b`](de63a740b8) build(deps): bump golangci/golangci-lint-action from 6.1.1 to 6.2.0 - Fix lost container logs from quickly closing io ([#​12376](https://redirect.github.com/containerd/containerd/pull/12376)) - [`f953ee8a3`](f953ee8a3c) bugfix:fix container logs lost because io close too quickly - CI: update Fedora to 43 ([#​12448](https://redirect.github.com/containerd/containerd/pull/12448)) - [`f6f15f513`](f6f15f5135) CI: update Fedora to 43 - Disable event subscriber during task cleanup ([#​12406](https://redirect.github.com/containerd/containerd/pull/12406)) - [`2a2329cbd`](2a2329cbd0) cri/server/podsandbox: disable event subscriber - CI: skip ubuntu-24.04-arm on private repos ([#​12428](https://redirect.github.com/containerd/containerd/pull/12428)) - [`dfb954743`](dfb9547437) CI: skip ubuntu-24.04-arm on private repos - Remove additional fuzzers from instrumentation repo ([#​12420](https://redirect.github.com/containerd/containerd/pull/12420)) - [`f6b02f6bb`](f6b02f6bb8) Remove additional fuzzers from CI - runc:Update runc binary to v1.3.1 ([#​12275](https://redirect.github.com/containerd/containerd/pull/12275)) - [`75c13ee3f`](75c13ee3fc) runc:Update runc binary to v1.3.1 - Add SystemdCgroup to default runtime options ([#​12254](https://redirect.github.com/containerd/containerd/pull/12254)) - [`427cdd06c`](427cdd06c9) add SystemdCgroup to default runtime options - install-runhcs-shim: fetch target commit instead of tags ([#​12255](https://redirect.github.com/containerd/containerd/pull/12255)) - [`0b35e19fb`](0b35e19fb1) install-runhcs-shim: fetch target commit instead of tags - Fix userns with container image VOLUME mounts that need copy ([#​12241](https://redirect.github.com/containerd/containerd/pull/12241)) - [`3212afc2f`](3212afc2f2) integration: Add test for directives with userns - [`b855c6e10`](b855c6e103) cri: Fix userns with Dockerfile VOLUME mounts that need copy - Fix overlayfs issues related to user namespace ([#​12223](https://redirect.github.com/containerd/containerd/pull/12223)) - [`05c0c99f4`](05c0c99f43) core/mount: Retry unmounting idmapped directories - [`afdede4ce`](afdede4ced) core/mount: Test cleanup of DoPrepareIDMappedOverlay() - [`47205f814`](47205f814d) core/mount: Properly cleanup on doPrepareIDMappedOverlay errors - [`6f4abd970`](6f4abd970a) core/mount: Don't call nil function on errors - [`a2f0d65d7`](a2f0d65d78) core/mount: Only idmap once per overlayfs, not per layer - [`1c32accd7`](1c32accd71) Make ovl idmap mounts read-only - ci: bump Go 1.23.12, 1.24.6 ([#​12187](https://redirect.github.com/containerd/containerd/pull/12187)) - [`9e72e91e6`](9e72e91e63) ci: bump Go 1.23.12, 1.24.6 - Create bootstrap.json with 0644 permission ([#​12184](https://redirect.github.com/containerd/containerd/pull/12184)) - [`009622e04`](009622e042) fix: create bootstrap.json with 0644 permission - Fix pidfd leak in UnshareAfterEnterUserns ([#​12178](https://redirect.github.com/containerd/containerd/pull/12178)) - [`5bec0a332`](https://redirec </details> --- ### Configuration 📅 **Schedule**: Branch creation - "" (UTC), Automerge - Monday through Friday ( * * * * 1-5 ) (UTC). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://redirect.github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://redirect.github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNjQuMCIsInVwZGF0ZWRJblZlciI6IjM5LjI2NC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiLCJpbXBhY3Qvbm8tY2hhbmdlbG9nLXJlcXVpcmVkIl19--> --------- Co-authored-by: pulumi-renovate[bot] <189166143+pulumi-renovate[bot]@users.noreply.github.com> Co-authored-by: pulumi-bot <bot@pulumi.com>
This commit is contained in:
pulumi-renovate[bot]
committed by
GitHub
GitHub
parent
c7ab0e0f35
commit
f1ff9e765f
11
go.mod
11
go.mod
@@ -35,7 +35,7 @@ require (
|
||||
go.opentelemetry.io/otel/trace v1.36.0
|
||||
go.uber.org/mock v0.5.2
|
||||
golang.org/x/crypto v0.45.0
|
||||
golang.org/x/exp v0.0.0-20250408133849-7e4ce0ab07d0
|
||||
golang.org/x/exp v0.0.0-20250711185948-6ae5c78190dc
|
||||
google.golang.org/protobuf v1.36.6
|
||||
gopkg.in/yaml.v3 v3.0.1
|
||||
)
|
||||
@@ -140,7 +140,7 @@ require (
|
||||
github.com/compose-spec/compose-go/v2 v2.4.8 // indirect
|
||||
github.com/containerd/console v1.0.4 // indirect
|
||||
github.com/containerd/containerd/api v1.8.0 // indirect
|
||||
github.com/containerd/containerd/v2 v2.0.3 // indirect
|
||||
github.com/containerd/containerd/v2 v2.0.7 // indirect
|
||||
github.com/containerd/continuity v0.4.5 // indirect
|
||||
github.com/containerd/errdefs v1.0.0 // indirect
|
||||
github.com/containerd/errdefs/pkg v0.3.0 // indirect
|
||||
@@ -198,7 +198,7 @@ require (
|
||||
github.com/go-toolsmith/astp v1.1.0 // indirect
|
||||
github.com/go-toolsmith/strparse v1.1.0 // indirect
|
||||
github.com/go-toolsmith/typep v1.1.0 // indirect
|
||||
github.com/go-viper/mapstructure/v2 v2.0.0 // indirect
|
||||
github.com/go-viper/mapstructure/v2 v2.4.0 // indirect
|
||||
github.com/go-xmlfmt/xmlfmt v1.1.2 // indirect
|
||||
github.com/gobwas/glob v0.2.3 // indirect
|
||||
github.com/godbus/dbus/v5 v5.1.0 // indirect
|
||||
@@ -418,7 +418,7 @@ require (
|
||||
github.com/tonistiigi/vt100 v0.0.0-20240514184818-90bafcd6abab // indirect
|
||||
github.com/uber/jaeger-client-go v2.30.0+incompatible // indirect
|
||||
github.com/uber/jaeger-lib v2.4.1+incompatible // indirect
|
||||
github.com/ulikunitz/xz v0.5.12 // indirect
|
||||
github.com/ulikunitz/xz v0.5.15 // indirect
|
||||
github.com/ultraware/funlen v0.1.0 // indirect
|
||||
github.com/ultraware/whitespace v0.1.1 // indirect
|
||||
github.com/uudashr/gocognit v1.1.2 // indirect
|
||||
@@ -467,10 +467,9 @@ require (
|
||||
golang.org/x/sys v0.38.0 // indirect
|
||||
golang.org/x/term v0.37.0 // indirect
|
||||
golang.org/x/text v0.31.0 // indirect
|
||||
golang.org/x/time v0.6.0 // indirect
|
||||
golang.org/x/time v0.12.0 // indirect
|
||||
golang.org/x/tools v0.38.0 // indirect
|
||||
golang.org/x/tools/go/expect v0.1.1-deprecated // indirect
|
||||
golang.org/x/tools/go/packages/packagestest v0.1.1-deprecated // indirect
|
||||
golang.org/x/tools/godoc v0.1.0-deprecated // indirect
|
||||
golang.org/x/xerrors v0.0.0-20231012003039-104605ab7028 // indirect
|
||||
google.golang.org/api v0.169.0 // indirect
|
||||
|
||||
Reference in New Issue
Block a user