Bug#1066965: bookworm-pu: package newlib/3.3.0-2
I finally was able to make room for a newlib build, and as uploaded the
fix a few minutes ago. Included is the final diff. I dropped the
switch to the QA team, as this package is not maintained by the gcc
group in unstable, and went with the more traditional version number
scheme.
diff --git a/debian/changelog b/debian/changelog
index b3e3ef851..0b92b542b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+newlib (3.3.0-1.3+deb12u1) bookworm; urgency=medium
+
+ * Team approved upload.
+ * Changed maintainer to reflect the ones listed in unstable.
+ * Added mallocr-CVE-2021-3420.patch to solve incorrect overflow
+check in malloc and friends (Closes: #984446).
+
+ -- Petter Reinholdtsen Mon, 22 Jul 2024 09:42:18 +0200
+
newlib (3.3.0-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff --git a/debian/control b/debian/control
index ff12d0bc5..a4b7bc142 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,8 @@
Source: newlib
Section: devel
Priority: optional
-Maintainer: Agustin Henze
+Maintainer: Debian GCC Maintainers
+Uploaders: Matthias Klose
Build-Depends:
debhelper (>= 9),
texinfo,
diff --git a/debian/gbp.conf b/debian/gbp.conf
index f4a0824a9..04f21b160 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,6 +1,7 @@
[DEFAULT]
pristine-tar = True
merge = True
+debian-branch = debian/bookworm
[import-orig]
postimport = gbp dch --debian-branch=$GBP_BRANCH
--new-version=$GBP_DEBIAN_VERSION
diff --git a/debian/patches/mallocr-CVE-2021-3420.patch
b/debian/patches/mallocr-CVE-2021-3420.patch
new file mode 100644
index 0..cd93fa41e
--- /dev/null
+++ b/debian/patches/mallocr-CVE-2021-3420.patch
@@ -0,0 +1,50 @@
+From aa106b29a6a8a1b0df9e334704292cbc32f2d44e Mon Sep 17 00:00:00 2001
+From: Corinna Vinschen
+Date: Tue, 17 Nov 2020 10:50:57 +0100
+Subject: malloc/nano-malloc: correctly check for out-of-bounds allocation reqs
+Origin:
https://keithp.com/cgit/picolibc.git/patch/newlib/libc/stdlib/mallocr.c?id=aa106b29a6a8a1b0df9e334704292cbc32f2d44e
+Forwarded: not-needed
+
+The overflow check in mEMALIGn erroneously checks for INT_MAX,
+albeit the input parameter is size_t. Fix this to check for
+__SIZE_MAX__ instead. Also, it misses to check the req against
+adding the alignment before calling mALLOc.
+
+While at it, add out-of-bounds checks to pvALLOc, nano_memalign,
+nano_valloc, and Cygwin's (unused) dlpvalloc.
+
+Signed-off-by: Corinna Vinschen
+---
+ newlib/libc/stdlib/mallocr.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+(limited to 'newlib/libc/stdlib/mallocr.c')
+
+diff --git a/newlib/libc/stdlib/mallocr.c b/newlib/libc/stdlib/mallocr.c
+index 9ad720ada..13d014cc8 100644
+--- a/newlib/libc/stdlib/mallocr.c
b/newlib/libc/stdlib/mallocr.c
+@@ -3055,7 +3055,7 @@ Void_t* mEMALIGn(RARG alignment, bytes) RDECL size_t
alignment; size_t bytes;
+ nb = request2size(bytes);
+
+ /* Check for overflow. */
+- if (nb > INT_MAX || nb < bytes)
++ if (nb > __SIZE_MAX__ - (alignment + MINSIZE) || nb < bytes)
+ {
+ RERRNO = ENOMEM;
+ return 0;
+@@ -3172,6 +3172,11 @@ Void_t* pvALLOc(RARG bytes) RDECL size_t bytes;
+ #endif
+ {
+ size_t pagesize = malloc_getpagesize;
++ if (bytes > __SIZE_MAX__ - pagesize)
++ {
++RERRNO = ENOMEM;
++return 0;
++ }
+ return mEMALIGn (RCALL pagesize, (bytes + pagesize - 1) & ~(pagesize - 1));
+ }
+
+--
+cgit v1.2.3
+
diff --git a/debian/patches/series b/debian/patches/series
index 3de9ae1fa..4b7d26190 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
reproducible-builds-locale.patch
fix-include-paths-nano-specs.patch
+mallocr-CVE-2021-3420.patch
--
Vennlig hilsen
Petter Reinholdtsen
Bug#1073983: transition: ocaml
Hi Paul, Le 21/07/2024 à 08:18, Paul Gevers a écrit : I've scheduled tests of all OCaml packages that provide tests (there are 86 of them). I did not specify any priority, I hope that's fine. That's fine for now. I guess you submitted via pasting the json you created in the self-service. Indeed. You get priority 10 that way by default. Did you we the service also has an API [1] you can use? The json for it is similar and it has a priority parameter. (@terceiro: does the self-service have an undocumented priority parameter, or is it really absent)? I am aware of the API, but have not yet integrated it into my workflow. Of course the cool thing you can do (and why I pointed you at britney2) is that you can also test for reverse (test) dependencies and check that *they* still work with the rebuild packages. Due to the way we do rebuilds in the archive (binNMU instead of NMU) we don't do those tests there (bug #944458), so it currently has added value if you could already check. To be clear, I'm not asking you to do it, I'm making you aware of these things, such that you can take it along if you so wish. I've added packages that declare rebuilt packages in their testsuite-triggers field. That makes a total of 104 packages. I've scheduled those packages, and it revealed 5 failures: - bdebstrap: seems unrelated to OCaml (rather to Python I'd say) - coq-unimath: expected (not rebuilt because of resource exhaustion) - frama-c: to be investigated - ocaml-rope: to be investigated - opam: already investigated (see my previous mail) PS: one other idea I'm having. There are multiple teams doing these kind of rebuilds and archive creation; does each have their own tools and does it their own way, I guess so? Has anybody ever tried to have the teams join forces? ruby, perl, python and ocaml I already know of. (I fear I'm hearing PPA/bicksheds/debusine resonating in my question). I guess so, too. There is also (at least) haskell. I've been working on my transition scripts since at least 2012 (first upload of ben to Debian). At that time, there was no tool suitable to prepare OCaml transitions with its idiosyncrasies. Since them, I incrementally improve them at each OCaml transition. I tried to make my scripts generic: https://salsa.debian.org/debian/ben/-/tree/master/examples/transition-scripts If anybody wants to use them in another context, I can help. But it would seem incongruous to me to promote my own tools to other circles without knowing their needs and workflows. Cheers, -- Stéphane
Bug#1072248: runc 1.0.0~rc93+ds1-5+deb11u4 flagged for acceptance
Hi Jonathan, Am Montag, dem 01.07.2024 um 18:49 +0100 schrieb Jonathan Wiltshire: [..] > Please don't change history, and send a debdiff (relative to u4) of a > proposed upload fixing the regressions as 1.0.0~rc93+ds1-5+deb11u5 and a > proper changelog. Do not upload without further approval. Please find attached the debdiff. The u4 upload was missing just one patch. I'm currently looking into the build issues you mentioned. Regards, Daniel diff -Nru runc-1.0.0~rc93+ds1/debian/changelog runc-1.0.0~rc93+ds1/debian/changelog --- runc-1.0.0~rc93+ds1/debian/changelog 2024-06-28 00:16:20.0 +0200 +++ runc-1.0.0~rc93+ds1/debian/changelog 2024-06-28 00:56:20.0 +0200 @@ -1,3 +1,16 @@ +runc (1.0.0~rc93+ds1-5+deb11u5) bullseye; urgency=medium + + * Non-maintainer upload by the Debian LTS Team. + * d/changelog: Cleaned up the last entry for 1.0.0~rc93+ds1-5+deb11u4 +removing some superflous entries. + * d/patches/CVE-2023-27561-and-CVE-2023-28642: Added to fix CVE-2023-27561 +and CVE-2023-27561. +- It was found that the fix for CVE-2021-30465 introduced a regression in + regards to CVE-2019-19921 which results in an incorrect access control + leading to privilege escalation and bypassing apparmor. + + -- Daniel Leidert Fri, 28 Jun 2024 00:56:20 +0200 + runc (1.0.0~rc93+ds1-5+deb11u4) bullseye; urgency=medium * Non-maintainer upload by the Debian LTS Team. @@ -15,11 +28,6 @@ - It was found that rootless runc makes `/sys/fs/cgroup` writable under specific conditions. A container may then gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host. - * Update changelog for 1.0.0~rc93+ds1-5+deb11u4~1.gbpce2b39 release - * Update patch for download URLs of busybox tarball - * Add patch to fix CVE-2021-43784.patch - * Add patch to fix tests with newer kernels - * Add patch to fix CVE-2023-25809 -- Daniel Leidert Fri, 28 Jun 2024 00:16:20 +0200 diff -Nru runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml --- runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml 2024-06-28 00:16:20.0 +0200 +++ runc-1.0.0~rc93+ds1/debian/.gitlab-ci.yml 2024-06-28 00:56:20.0 +0200 @@ -1,37 +1,10 @@ --- -# https://docs.gitlab.com/ce/ci/yaml/#include include: - - remote: https://salsa.debian.org/onlyjob/ci/raw/master/onlyjob-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml -## "amd64-unstable" always runs by default followed by lintian. - -## Only for arch:all packages - remove if not required: -binary-indep: - extends: .build-indep - -## Job to check Build-Depends versioning: -amd64-testing_unstable: - extends: .build - variables: -arch: amd64 -dist: testing_unstable - -i386-unstable: - extends: .build - variables: -arch: i386 -dist: unstable - -amd64-experimental: - extends: .build - variables: -arch: amd64 -dist: experimental - -amd64-stable: - extends: .build - when: manual - allow_failure: true - variables: -arch: amd64 -dist: stable +variables: + RELEASE: 'bullseye' + SALSA_CI_COMPONENTS: 'main contrib non-free' + SALSA_CI_DISABLE_REPROTEST: 1 + SALSA_CI_DISABLE_LINTIAN: 1 diff -Nru runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch --- runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch 1970-01-01 01:00:00.0 +0100 +++ runc-1.0.0~rc93+ds1/debian/patches/CVE-2023-27561-and-CVE-2023-28642.patch 2024-06-28 00:56:20.0 +0200 @@ -0,0 +1,109 @@ +From: Kir Kolyshkin +Date: Thu, 16 Mar 2023 14:35:50 -0700 +Subject: [PATCH] Prohibit /proc and /sys to be symlinks + +Commit 3291d66b9844 introduced a check for /proc and /sys, making sure +the destination (dest) is a directory (and not e.g. a symlink). + +Later, a hunk from commit 0ca91f44f switched from using filepath.Join +to SecureJoin for dest. As SecureJoin follows and resolves symlinks, +the check whether dest is a symlink no longer works. + +To fix, do the check without/before using SecureJoin. + +Add integration tests to make sure we won't regress. + +Signed-off-by: Kir Kolyshkin +(cherry picked from commit 0d72adf96dda1b687815bf89bb245b937a2f603c) +Signed-off-by: Sebastiaan van Stijn + +This patch fixes both, CVE-2023-27561 and CVE-2023-28642 + +Acked-by: Daniel Leidert +Origin: https://github.com/opencontainers/runc/commit/0abab45c9b97c113ff2cdc16f3a7388444c3fbec.patch +Forwarded: not-needed +--- + libcontainer/rootfs_linux.go | 23 +-- + tests/integration/mask.bats | 19 +++ + 2 files changed, 36 insertions(+), 6 deletions(-) + +diff --git a/libcontainer/rootfs_linux.go b/libcontainer/rootfs_linux.go +index 4791ceb..07303b0 100644 +--- a/libcontainer/rootfs_linux.go b/libcontainer/rootfs_
Bug#1072248: runc 1.0.0~rc93+ds1-5+deb11u4 flagged for acceptance
Am Dienstag, dem 23.07.2024 um 01:12 +0200 schrieb Daniel Leidert: > Hi Jonathan, > > Am Montag, dem 01.07.2024 um 18:49 +0100 schrieb Jonathan Wiltshire: > > > [..] > > Please don't change history, and send a debdiff (relative to u4) of a > > proposed upload fixing the regressions as 1.0.0~rc93+ds1-5+deb11u5 and a > > proper changelog. Do not upload without further approval. > > Please find attached the debdiff. The u4 upload was missing just one > patch. > > I'm currently looking into the build issues you mentioned. The build failures are unreproducible on porter machines. There, the package builds just fine. Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: Coordingating/planning various golang transitions
Are there any objections to starting the process of uploading packages to unstable, following the outline that Reinhard provided (quoted at the end of the message)? I'm here at DebCamp and would be happy to start working through the uploads and any other hand-holding to get the migration underway. I know we've got an item on the BoF to discuss this, but maybe by next week we could have a status update of how things are going? I've spend some time today checking things in experimental and building a few other packages against those versions, and at least from what I have testing things appear to be working OK with the newer versions. Mathias On Sat, 2024-07-13 at 20:48 -0400, Reinhard Tartler wrote: > My pitch would be to start with sourceful uploads of (and in that order): > > - golang-google-genproto > - golang-google-grpc > - golang-github-grpc-ecosystem-grpc-gateway.v2 > - golang-github-google-cel-go > - golang-opentelemetry-otel > - golang-github-googleapis-gnostic > - etcd > - golang-gogottrpc > - golang-github-containerd-btrfs > - golang-github-containerd-go-cni > - golang-github-containerd-go-runc > - golang-github-coreos-bbolt > - golang-github-google-certificate-transparency > - golang-github-lightstep-lightstep-tracer-common > - golang-github-kurin-blazer > - golang-google-cloud > - golang-github-containerd-cgroups > - golang-github-containerd-typeurl > - containerd > - golang-github-cloudflare-cfssl > - rootlesskit > - docker.io > - golang-github-fsouza-go-dockerclient > - golang-github-openshift-imagebuilder > - golang-github-containers-storage > - golang-github-containers-image > - golang-github-containers-common > - golang-github-containers-buildah > - libpod signature.asc Description: This is a digitally signed message part
Re: Coordingating/planning various golang transitions
On Jul 23, 2024 12:28 PM, Mathias Gibbens wrote: > > Are there any objections to starting the process of uploading > packages to unstable, following the outline that Reinhard provided > (quoted at the end of the message)? I'm here at DebCamp and would be > happy to start working through the uploads and any other hand-holding > to get the migration underway. > > I know we've got an item on the BoF to discuss this, but maybe by > next week we could have a status update of how things are going? > > I've spend some time today checking things in experimental and > building a few other packages against those versions, and at least from > what I have testing things appear to be working OK with the newer > versions. > > Mathias I'm with Mathias on this thinking we must move forward during debcamp. I'd be helping with it if the team gives us a go... :) Thomas > > On Sat, 2024-07-13 at 20:48 -0400, Reinhard Tartler wrote: > > My pitch would be to start with sourceful uploads of (and in that order): > > > > - golang-google-genproto > > - golang-google-grpc > > - golang-github-grpc-ecosystem-grpc-gateway.v2 > > - golang-github-google-cel-go > > - golang-opentelemetry-otel > > - golang-github-googleapis-gnostic > > - etcd > > - golang-gogottrpc > > - golang-github-containerd-btrfs > > - golang-github-containerd-go-cni > > - golang-github-containerd-go-runc > > - golang-github-coreos-bbolt > > - golang-github-google-certificate-transparency > > - golang-github-lightstep-lightstep-tracer-common > > - golang-github-kurin-blazer > > - golang-google-cloud > > - golang-github-containerd-cgroups > > - golang-github-containerd-typeurl > > - containerd > > - golang-github-cloudflare-cfssl > > - rootlesskit > > - docker.io > > - golang-github-fsouza-go-dockerclient > > - golang-github-openshift-imagebuilder > > - golang-github-containers-storage > > - golang-github-containers-image > > - golang-github-containers-common > > - golang-github-containers-buildah > > - libpod > On Jul 23, 2024 12:28 PM, Mathias Gibbens wrote: Are there any objections to starting the process of uploading packages to unstable, following the outline that Reinhard provided (quoted at the end of the message)? I'm here at DebCamp and would be happy to start working through the uploads and any other hand-holding to get the migration underway. I know we've got an item on the BoF to discuss this, but maybe by next week we could have a status update of how things are going? I've spend some time today checking things in experimental and building a few other packages against those versions, and at least from what I have testing things appear to be working OK with the newer versions. Mathias On Sat, 2024-07-13 at 20:48 -0400, Reinhard Tartler wrote: > My pitch would be to start with sourceful uploads of (and in that order): > > - golang-google-genproto > - golang-google-grpc > - golang-github-grpc-ecosystem-grpc-gateway.v2 > - golang-github-google-cel-go > - golang-opentelemetry-otel > - golang-github-googleapis-gnostic > - etcd > - golang-gogottrpc > - golang-github-containerd-btrfs > - golang-github-containerd-go-cni > - golang-github-containerd-go-runc > - golang-github-coreos-bbolt > - golang-github-google-certificate-transparency > - golang-github-lightstep-lightstep-tracer-common > - golang-github-kurin-blazer > - golang-google-cloud > - golang-github-containerd-cgroups > - golang-github-containerd-typeurl > - containerd > - golang-github-cloudflare-cfssl > - rootlesskit > - docker.io > - golang-github-fsouza-go-dockerclient > - golang-github-openshift-imagebuilder > - golang-github-containers-storage > - golang-github-containers-image > - golang-github-containers-common > - golang-github-containers-buildah > - libpod
Bug#1075938: marked as done (transition: glibc 2.39)
Your message dated Tue, 23 Jul 2024 15:32:09 +0900 with message-id and subject line Re: Bug#1075938: transition: glibc 2.39 has caused the Debian Bug report #1075938, regarding transition: glibc 2.39 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1075938: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075938 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: gl...@packages.debian.org Control: affects -1 + src:glibc User: release.debian@packages.debian.org Usertags: transition Dear release team, I would like to get a transition slot for glibc 2.39. It has been available in experimental for two months already. It has been built successfully on all release architectures and most ports architectures. The experimental pseudo-excuses look good overall. The current known issues are available in the BTS using the glibc2.39 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=glibc2.39;users=debian-gl...@lists.debian.org gopacket has a patch available and I can take care of NMUing if it is not fixed before the transition starts. For aspectc++, cbmc and rocm-hipamd, the situation is a bit more complex. Those packages have issues with the types introduced on the arm64 version of bits/math-vector.h. Those are guarded by clang or gcc version checks, but the guards are ignored by the packages for various reasons. A workaround is present in glibc 2.38, but it can't be ported easily in glibc 2.39. I therefore propose to remove the corresponding arm64 packages from the archive. aspectc++ and cbmc are leaf packages. For rocm-hipamd, this also means removing 15 reverse dependencies. As glibc is using symbol versioning, there is no soname change. That said a few packages are using libc internal symbols and have to be rebuilt for this transition. Here is the corresponding ben file: title = "glibc"; is_affected = .depends ~ /libc[0-9.]* \(< from ISO C2X They are unlikely to be widely used at this point, but at least systemd uses some of them. This might block their migration to testing during the transition. Thanks for considering. Regards, Aurelien --- End Message --- --- Begin Message --- glibc/2.39-4 has migrated. I am closing this bug.--- End Message ---
