Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-06-24 Thread Petter Reinholdtsen
[Salvatore Bonaccorso]
> Did you saw Adam's confirmation on this (with the comments about the
> version)?

Yes, but in the month that went between me working on newlib and the
confirmation showing up, I filled up my disk and have not had time to
free enough space to be able to build newlib again, so the rebuild and
upload is waiting in limbo. :)

Perhaps someone else several GiB (at least 3.5, I believe) of free disk
space can look at it before I get around to it?

-- 
Vennlig hilsen
Petter Reinholdtsen



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-06-22 Thread Salvatore Bonaccorso
Hi Petter,

On Sat, May 25, 2024 at 09:44:06PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2024-03-16 at 09:09 +0100, Petter Reinholdtsen wrote:
> > +newlib (3.3.0-2) bookworm; urgency=medium
> > 
> 
> As Salvatore already noted, that's not a conventional version number
> for a stable upload, but can be used iff no such version has ever been
> used for a package uploaded to Debian (or included as a changelog
> stanza in d/changelog for any package uploaded to Debian) in the past.
> 
> > +
> > +  * QA upload.
> > +  * Orphan package to reflect status in Unstable.
> 
> Although this is harmless, note that it's also mostly redundant, as
> nothing actually looks at / acts on the maintainer fields of packages
> in stable (or older).
> 
> Please go ahead.

Did you saw Adam's confirmation on this (with the comments about the
version)?

Regards,
Salvatore



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-05-25 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2024-03-16 at 09:09 +0100, Petter Reinholdtsen wrote:
> +newlib (3.3.0-2) bookworm; urgency=medium
> 

As Salvatore already noted, that's not a conventional version number
for a stable upload, but can be used iff no such version has ever been
used for a package uploaded to Debian (or included as a changelog
stanza in d/changelog for any package uploaded to Debian) in the past.

> +
> +  * QA upload.
> +  * Orphan package to reflect status in Unstable.

Although this is harmless, note that it's also mostly redundant, as
nothing actually looks at / acts on the maintainer fields of packages
in stable (or older).

Please go ahead.

Regards,

Adam



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-05-11 Thread Petter Reinholdtsen
[Salvatore Bonaccorso]
> Note that if you are confident that the upload is accepted as it, you
> *could* already upload according to the improved workflow. *But* given
> the uncertainity if SRM want you to have the version changed I would
> wait for their ack.

I do not feel that confident, but I do feel some surprise that it should
take two months to get feedback from the release managers.

I'll give it another week and close this proposal and move on if I do
not hear any conclusion.

-- 
Happy hacking
Petter Reinholdtsen



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-04-06 Thread Salvatore Bonaccorso
Hi,

On Tue, Apr 02, 2024 at 12:36:53PM +0200, Petter Reinholdtsen wrote:
> 
> Btw, what is the timeline for approval or rejection for this security
> upload proposal?

Note that if you are confident that the upload is accepted as it, you
*could* already upload according to the improved workflow. *But* given
the uncertainity if SRM want you to have the version changed I would
wait for their ack.

Regards,
Salvatore



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-04-02 Thread Petter Reinholdtsen


Btw, what is the timeline for approval or rejection for this security
upload proposal?
-- 
Happy hacking
Petter Reinholdtsen



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-03-20 Thread Petter Reinholdtsen
[Salvatore Bonaccorso]
> Usually you would choose for this update 3.3.0-1.3+deb12u1, but given
> 3.3.0-2 was never present in unstable and the version later moved on,
> this is in theory possible.

That reasoning is the same as mine.  I also wanted to drop the NMU
version number part, to make it more obvoius that this is not a NMU.

> I would add as well the bug closer for #984446.

Good point.  git updated.

-- 
Happy hacking
Petter Reinholdtsen



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-03-20 Thread Salvatore Bonaccorso
Hi

[disclaimer, not an authoritative answer as not part of the stable
release managers]

On Sat, Mar 16, 2024 at 09:09:05AM +0100, Petter Reinholdtsen wrote:
> 
> Package: release.debian.org
> 
> The https://tracker.debian.org/pkg/newlib > package got an open
> security problem with malloc and friends in stable and oldstable, see
> https://bugs.debian.org/984446 > for the CVE issue.  The package
> is orphaned.
> 
> I would like to fix the bug at least in stable, and propose the
> following upload.  The change is already in the git repo on salsa in the
> debian/bookworm branch.  The problem is already fixed in unstable and
> testing with a new version of the upstream code.  The fix to stable is
> only the minimal patch to solve the issue.
> 
> I propose to use the version number 3.3.0-2, but am open to better
> proposals.  The version in testing is 4.4.0.20231231-2.

Usually you would choose for this update 3.3.0-1.3+deb12u1, but given
3.3.0-2 was never present in unstable and the version later moved on,
this is in theory possible.

> 
> Complete proposed patch is below:
> 
> diff --git a/debian/changelog b/debian/changelog
> index b3e3ef851..1c8ddc5cb 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +newlib (3.3.0-2) bookworm; urgency=medium
> +
> +  * QA upload.
> +  * Orphan package to reflect status in Unstable.
> +  * Added mallocr-CVE-2021-3420.patch to solve incorrect overflow
> +check in malloc and friends.

I would add as well the bug closer for #984446.

Regards,
Salvatore



Bug#1066965: bookworm-pu: package newlib/3.3.0-2

2024-03-16 Thread Petter Reinholdtsen


Package: release.debian.org

The https://tracker.debian.org/pkg/newlib > package got an open
security problem with malloc and friends in stable and oldstable, see
https://bugs.debian.org/984446 > for the CVE issue.  The package
is orphaned.

I would like to fix the bug at least in stable, and propose the
following upload.  The change is already in the git repo on salsa in the
debian/bookworm branch.  The problem is already fixed in unstable and
testing with a new version of the upstream code.  The fix to stable is
only the minimal patch to solve the issue.

I propose to use the version number 3.3.0-2, but am open to better
proposals.  The version in testing is 4.4.0.20231231-2.

Complete proposed patch is below:

diff --git a/debian/changelog b/debian/changelog
index b3e3ef851..1c8ddc5cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+newlib (3.3.0-2) bookworm; urgency=medium
+
+  * QA upload.
+  * Orphan package to reflect status in Unstable.
+  * Added mallocr-CVE-2021-3420.patch to solve incorrect overflow
+check in malloc and friends.
+
+ -- Petter Reinholdtsen   Sat, 16 Mar 2024 08:53:41 +0100
+
 newlib (3.3.0-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index ff12d0bc5..4daa4e559 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
 Source: newlib
 Section: devel
 Priority: optional
-Maintainer: Agustin Henze 
+Maintainer: Debian QA Group 
 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