CVE-2025-27612
Libcontainer is affected by capabilities elevation similar to GHSA-f3fp-gc8g-vw66
描述
### Impact In libcontainer, while creating a tenant container, the tenant builder accepts a list of capabilities to be added in the spec of tenant container. Code can be seen [here](https://github.com/youki-dev/youki/blob/9e63fa4da1672a78ca45100f3059a732784a5174/crates/libcontainer/src/container/tenant_builder.rs#L408) . The logic here adds the given capabilities to all capabilities of main container if present in spec, otherwise simply set provided capabilities as capabilities of the tenant container. However, GHSA-f3fp-gc8g-vw66 was opened on runc mentioning that setting inherited caps in any case for tenant container can lead to elevation of capabilities. For this, they added a fix [here](https://github.com/opencontainers/runc/blob/986451c24e17c8d4be3c454f60b1f7be4af3e8b4/exec.go#L234-L242) where they never set new inherited caps on tenant, and set ambient caps only if original container had inherited caps. Similarly crun never sets inherited caps as can be seen [here](https://github.com/containers/crun/blob/3ec6298abd79e144fbf3fa6db90793ff4c0516f9/src/exec.c#L319). > [!NOTE] This does not affect youki binary itself, as the exec implementation is partially broken and does not pass on the user-provided caps to tenant containers, this is only applicable if you are using libcontainer directly and using the tenant builder. ### Workarounds - Do not pass any user-provided capabilities to the tenant builder, in which case no capabilities will be set on tenant. - Alternatively you can verify the capabilities of original container and filter the user passed capabilities before setting them on tenant. ### References - https://github.com/opencontainers/runc/security/advisories/GHSA-f3fp-gc8g-vw66 - https://man7.org/linux/man-pages/man7/capabilities.7.html
如何修補 CVE-2025-27612
要修補 CVE-2025-27612,請將受影響套件升級到下列已修補版本。
- —未列出修補版本
- —升級至 0.5.3 或更新版本
CVE-2025-27612 正在被利用嗎?
低 — EPSS 為 0.2%,目前沒有觀察到大規模利用活動。