Hi, The following vulnerabilities were published for runc. CVE-2025-31133[0], CVE-2025-52565[1] and CVE-2025-52881[2]. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2025-31133 https://www.cve.org/CVERecord?id=CVE-2025-31133 [1] https://security-tracker.debian.org/tracker/CVE-2025-52565 https://www.cve.org/CVERecord?id=CVE-2025-52565 [2] https://security-tracker.debian.org/tracker/CVE-2025-52881 https://www.cve.org/CVERecord?id=CVE-2025-52881 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
We believe that the bug you reported is fixed in the latest version of
runc, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1120140@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Reinhard Tartler <siretart@tauware.de> (supplier of updated runc package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 15 Nov 2025 18:28:40 -0500
Source: runc
Architecture: source
Version: 1.3.3+ds1-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
Changed-By: Reinhard Tartler <siretart@tauware.de>
Closes: 1120140
Changes:
runc (1.3.3+ds1-1) experimental; urgency=medium
.
* New upstream release:
- Fixes CVE-2025-31133, CVE-2025-52565, CVE-2025-52881,
Closes: #1120140
* refresh patches
* debian/control:
- tighten dependency on containerd/console
- build against golang-github-cyphar-filepath-securejoin-dev 0.5
* debian/copyright: clarify license: Apache-2.0 & MPL-2.0
* Backport upstream patches:
- libct: use manager.AddPid to add exec to cgroup
Checksums-Sha1:
0f4ee10d0b93ef187b05df575fcf194e2222740c 3464 runc_1.3.3+ds1-1.dsc
e0b28fe85f746d199ba08ed3b68ada28cad2e627 542300 runc_1.3.3+ds1.orig.tar.xz
f1b0dec782e960cfe7f2e9d41b7505add1b80dce 13188 runc_1.3.3+ds1-1.debian.tar.xz
Checksums-Sha256:
4a85d34ea47873d694e2708fb45be6d51986db20b945d8e5b14216426b212770 3464 runc_1.3.3+ds1-1.dsc
b5c86ad372d1b08f762a978efda6cca6eb806aa60641e792e864007c7c871d45 542300 runc_1.3.3+ds1.orig.tar.xz
d04f8dc3f5bb5d8723a26ab3b65b32306c9f11e26f347e1fe271b301b98affcd 13188 runc_1.3.3+ds1-1.debian.tar.xz
Files:
3db34c9521fffa71cbd35c80c16aa4ea 3464 admin optional runc_1.3.3+ds1-1.dsc
2cbd46dac9598fcaa9e7c096b5eb6908 542300 admin optional runc_1.3.3+ds1.orig.tar.xz
4aad993161676ab18a13b775fc2ab99e 13188 admin optional runc_1.3.3+ds1-1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAmkZsCMUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJssLwg/7BYTLiH3XgcKKzPrLjyEJhmZ9B6ox
dQX09287da65Wn8J7tAs+yOiSICZjVA6SCrmk7d5JvmWnL1Tjx1Yvwaw9tUC9z1y
YVm8nhClmrvUsJdfzV+ljocnVVSkCIbbsEZNRR7DyDfFwccb6RyZiUG7fB3Wz9xT
3jVDIvEu2UL1M02Z0/THsWYrKTl3eAbp5v6n2dSjQmqB5Fe/YTynseLy82Hq/lHR
wRUKpnUa3QAXDDRvEjmnxgB/53dfH8+DdOXmgNGiQxFwP+AdLb8CLQHWx2HFp1iV
bRxfCAo+hskuq1ZIlR5LAJYguxNWtVSSh020EwznxOyaqobaeQuQV2ZH04O0xNsF
jM6s+NLbUk5FMaRClid10FZrzT1sY1TeFsYG+2eOn/HXjcBqTWZVftgV4SzY+XAV
FkCRK/9nbJaRpi43sU5gS+mIHjqivPA/s/VPPdVbCPYnKeD8S10oh/+Sch5CbVPO
VjlVRVVxzQOlZszExnp7k0WQ6aN/SOBxoEHCGYlTWPvNlEBBkaqkdsW45KQJESYc
5utMZnNHOHIuSDrzHQHk6S7kzAz5oJlyEMg0wvUFfU6RIElra3Ndywndq6ZPUeZY
spnTTk/r2nwk1J+uk+CUYY5foRvpWn+p9JSzrwNXUx707F5Lb+asKExzIvL/o88x
CjcHlxHM/Wr523c=
=Kjjo
-----END PGP SIGNATURE-----
We believe that the bug you reported is fixed in the latest version of
runc, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1120140@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Reinhard Tartler <siretart@tauware.de> (supplier of updated runc package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 16 Nov 2025 11:28:16 -0500
Source: runc
Architecture: source
Version: 1.3.3+ds1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
Changed-By: Reinhard Tartler <siretart@tauware.de>
Closes: 1120140
Changes:
runc (1.3.3+ds1-2) unstable; urgency=medium
.
* Upload to unstable
* debian/control: Drop redundant Rules-Requires-Root
.
runc (1.3.3+ds1-1) experimental; urgency=medium
.
* New upstream release:
- Fixes CVE-2025-31133, CVE-2025-52565, CVE-2025-52881,
Closes: #1120140
* refresh patches
* debian/control:
- tighten dependency on containerd/console
- build against golang-github-cyphar-filepath-securejoin-dev 0.5
* debian/copyright: clarify licensing terms of this package
* Backport upstream patches:
- libct: use manager.AddPid to add exec to cgroup
Checksums-Sha1:
07135a9d2c7490be1b6b4e2d28977f749720148e 3464 runc_1.3.3+ds1-2.dsc
ffd1497e74a7296d6ab402ccb30002d4464b6db9 13228 runc_1.3.3+ds1-2.debian.tar.xz
Checksums-Sha256:
9a3cd60645378508cc7a3950fd9de0238eccebd90da6829ba07bc2b77e20f120 3464 runc_1.3.3+ds1-2.dsc
8f3cec0870c902f1b76f65f8a1a25f314cd27ff539457fcd37cc23a4303ac016 13228 runc_1.3.3+ds1-2.debian.tar.xz
Files:
12ffb1858f369ee6a20102255f597955 3464 admin optional runc_1.3.3+ds1-2.dsc
59f23f8977fc03b5febbc61f3a580cb8 13228 admin optional runc_1.3.3+ds1-2.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAmkZ/kkUHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJsudlA//UT8FQZ9pQlhmAGgjmjHrWStCkOm2
XFaM1sZSE7FVt6U2jyVzvlYmqBK9mV+scE3KlKuTW4bNpKRuLaaxqabd3AAKTMbs
X1bGZGdNsDqzPPAKcbAhV6Y70/warf7ikJCJH05g5/ZTtzAhi2xz+EyDztw4YRSa
8iMeDk0Fa9OsT9Wpzx59VR9dv0VJOAaqoE0r81CVkQPhBGUHjewoZIWaMjng4GCZ
R8pv4+F7PXynqrgM+vkcDnm0WWWSo1zxvTqoWtLDBtiPdYtPKkAcYmMEMVevnUwO
0r/JTUXN/P2W1c2pDHWY6MwThNrje8nUISuTOqOFMnBTCxAPz6SUKKE23+lHO6K+
ZkiFu/IVtHNFSwrWAjR2DGJHcJ77oO1th5cZOS8vuZnpfu+wxWKfQdqBAfl58+rk
KF1SifLauo7vdftyNy6GPUEWP0a04ePbDGw2HQcqJ6lo4Ka/HZDceRilUHwGT7hf
uX2F6kN2RO/B923n2AEUMxmSOtj0FPTepir4XCFqxkj/IDusxFbgx53nhqQNMeQm
SKlJuHbNrqFw33BDdtoMDtwpw5U4fs29kxTlBtgvJAamNRJYtA0jRG3lso+lRHIu
cE+jmZc+6iEz+M+9Ik4nlnPNeJzl432Kfm3BqTJaijz7IZ3zZoVLR3RoM+ia0+WZ
oCqsuVRXKlMuxxQ=
=BrsA
-----END PGP SIGNATURE-----
Salvatore Bonaccorso <carnil@debian.org> writes: Hi Salvatore (and everyone else CCed), I've taken a close look at the backport situation for Trixie (runc 1.1.15+ds1-2) and checked other distributions. The upstream patches (squashed tarball from https://seclists.org/oss-sec/2025/q4/138 attachment runc-patches-2025-11-05.tar.xz, applying to 1.2.7+) do not work cleanly on 1.1.15 due to refactors in 1.2 (e.g., openat2, cgroup v2, securejoin). Trixie summary: - ~70-80% of the ~20 patches conflict (e.g., in libcontainer/rootfs_linux.go, nsenter). - Requires bumping golang-github-cyphar-filepath-securejoin-dev, risking reverse dep breaks. - Effort: 80-150 hours over weeks for a tested backport. Other distros (as of 2025-12-03; no 1.1.15 backports found): Distribution Old version in LTS/old-stable Fix strategy + reference -------------------------------------------------------------------------------- Ubuntu 22.04 / 24.04 1.0.x / 1.1.12 Upgrade to 1.3.3 https://ubuntu.com/security/notices/USN-7851-1 https://ubuntu.com/security/notices/USN-7851-2 RHEL 8 / 9 1.2.5 Custom backports to 1.2.5 https://access.redhat.com/errata/RHSA-2025:19927 SUSE SLE 15 ~1.1.x Upgrade to 1.2.7 https://www.suse.com/support/update/announcement/2025/suse-su-20253951-1/ Fedora 41 1.1.x Upgrade to 1.3.3 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OROGIHQBV5TR2WUJZV5N4SOGYPXGKM5P/ I lack bandwidth for this (day job + other packages). As far as I can tell, all the issues are addressed in experimental/unstable/testing with 1.3.3+ds1-2. Options for Debian: - Full backport to 1.1.15 (expensive, no distro precedent). - Bump Trixie to 1.2.8/1.3.3 (i.e., introduce new source "runc-app that produces the `runc` binary", like Ubuntu). - Declare 1.1.x unsupported in Trixie; recommend podman/crun (which is a re-implementation of runc in C) Salvatore, Gianfranco, Jochen, Shengjing Zhu: Please do share your opinions and chime in on the best way forward here. Thanks, Reinhard
Hi Reinhard, * Reinhard Tartler <siretart@tauware.de> [2025-12-03 06:51]: Thanks for asking, currently I don't have capacity to work on it but I added a reference to your mail to the (E)LTS security tracker. Cheers Jochen
* Reinhard Tartler <siretart@tauware.de> [2025-12-03 06:51]: >- Bump Trixie to 1.2.8/1.3.3 (i.e., introduce new source "runc-app that produces the `runc` binary", like Ubuntu). Indeed, Ubuntu ships runc 1.3.3 in 22.04 LTS, 24.04 LTS and newer. However their runc source package embeds the complete vendor tree, and their Build-Depends are minimal. That's why it's fairly easy to rebuild this package for older Ubuntu releases. However in Debian we don't use the vendor tree, so it's a completely different story. I tried to rebuild runc 1.3.3 (currently in Sid) against Debian Trixie. Result: we need to bump 4 Build-Depends just to meet the constraints. I didn't go further. I tried something more realistic: rebuilding runc 1.2.9 against Trixie. Result: I had to bump 3 Build-Depends to fix FTBFS (as a shortcut, I just vendored it). After that, the package is built. I didn't test it. At this point I have two concerns: - I'm not sure it's feasible to upload new versions of the Build-Depends in Trixie: we risk break builds or regressions in other packages that use those Build-Depends. - I'm also interested in supporting Bookworm and Bullseye, and it's going to be even harder, or downright impossible, to rebuild runc 1.2.9 aginst those old releases. So, in short, and forgive me for stating the obvious: I think the approach of providing new versions of runc in old versions of Debian can only work if we use the embedded vendor tree to build it, just like Ubuntu does. *Do we want to do that* ? Another aspect that wasn't discussed yet: src:runc also provides the library golang-github-opencontainers-runc-dev. I don't know if the CVEs affect this code and therefore the reverse Build-Depends of it. Reinhard do you have any idea about that? Again, opinions from everyone welcome. Best, Arnaud
Hi, and rebuild Trixie. I Trixie. it. Depends 1.2.9 can CVEs Reinhard Thanks for working on the backports and for identifying the potential issues — that is very helpful. I had a similar discussion in Ubuntu a few years ago. As you’ve already noticed, we eventually decided that it was preferable to keep updating to newer upstream versions while avoiding breakage of reverse dependencies in the archive. The approach we took was to create separate source packages (e.g. src:runc-app, and similarly for containerd and docker.io) with embedded build dependencies, making them self-contained and not affecting other packages in the archive. Our assessment at the time was that most users rely primarily on the application rather than the provided library. Therefore, ensuring that the application itself receives security fixes — even if not an ideal solution — seemed better than leaving users with known vulnerabilities. The container ecosystem evolves very quickly, which makes backporting particularly time-consuming and, in many cases, still results in breaking changes. I wonder whether Debian would consider a similar approach in the interest of users. We are all aware of the downsides: vendoring build dependencies, introducing larger updates in stable releases, and the general trade-offs involved. However, the alternative is continuing to ship versions with known vulnerabilities. In the long run, users may decide to stop relying on the distribution packages and instead turn to external sources. These are just my thoughts on the matter, and I’m interested in hearing what others think. Lucas Kanashiro.