Bug#1016733: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.154-1~deb10u1

[Andreas Beckmann]

On 29/08/2022 09.39, Adam D. Barratt wrote:

Quick reminder that that's nowish. :)


I had been more VAC than planned ;-)


I spotted the buster upload; thanks. Given the versioning, we will also
need the bullseye upload to be in p-u by next weekend, when the window
for 11.5 closes.


390xx for bullseye-pu is uploaded as well, and PU bugs for the other 
drivers in stable have now been filed to fix the same CVEs...



Andreas

Bug#1018744: bullseye-pu: package inetutils/2:2.0-1+deb11u1

[Guillem Jover]

Hi!

Sorry, I'm updating the request as I found missing stuff while
preparing the companion update for buster!

On Tue, 2022-08-30 at 00:37:03 +0200, Guillem Jover wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: t...@security.debian.org

> [ Reason ]
> 
> A recent vulnerability (DoS) was reported upstream, for which I
> uploaded a fixed package to sid (will migrate tomorrow). There was a
> (minor) pending security update missing from bullseye. The security
> team (CCed) would prefer to see these handled as normal stable updates.

I'm adding a couple of patches to solve lingering buffer overflow issues
from #945861 and CVE-2019-0053.

> [ Impact ]
> 
> These are both security issues. One against malicious ftp servers
> which can end up controlling the client to connect to other hosts,
> the other a DoS on the telnetd server which makes it crash with
> specific two-byte payloads.

The additional patches are buffer overflows.

> [ Tests ]
> 
> For the ftp client, there's a test recipe at
> .
> 
> For the telnetd server there's a test recipe at
> 
> which amounts to «printf "\xff\xf7" | nc -n -v localhost 23».

The two new patches fix the following reproducers:

  $ DISPLAY=`perl -e 'print Ax"5"'` telnet -l`perl -e 'print "A"x5000'` 
localhost

and

  
https://raw.githubusercontent.com/hackerhouse-opensource/exploits/master/telnet_term_0day.py

> Both test recipes could be reproduced before, and do not work after
> the patched version.

> [ Risks ]
> 
> The fix for the ftp client has been in sid since 2021-09 with no
> reported regressions.
> 
> The fix for telnetd has not yet migrated to testing, but is few lines
> long fixing a couple of NULL pointer dereferences.

Both new fixes have been part of sid/testing for a while now.

> [ Checklist ]
> 
>   [√] *all* changes are documented in the d/changelog
>   [√] I reviewed all changes and I approve them
>   [√] attach debdiff against the package in (old)stable
>   [√] the issue is verified as fixed in unstable
> 
> [ Changes ]

  * telnet: Add checks for option reply parsing limits causing buffer
overflow induced crashes due to long option values.
Fixes CVE-2019-0053. Closes: #945861
  * Add patch from upstream to fix infinite loop causing a stack exhaustion
induced crash in telnet client due to malicious server commands.
Closes: #945861
>   * Fix inetutils-ftp security bug trusting FTP PASV responses.
> Fixes CVE-2021-40491. Closes: #993476
>   * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
> a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
> or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
> adapted by Erik Auerswald .

> [ Other info ]
> 
> None.

I'm attaching the refreshed debdiff.

Thanks,
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2021-02-05 23:14:20.0 +0100
+++ inetutils-2.0/debian/changelog  2022-08-30 13:34:41.0 +0200
@@ -1,3 +1,21 @@
+inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
+
+  * telnet: Add checks for option reply parsing limits causing buffer
+overflow induced crashes due to long option values.
+Fixes CVE-2019-0053. Closes: #945861
+  * Add patch from upstream to fix infinite loop causing a stack exhaustion
+induced crash in telnet client due to malicious server commands.
+Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Tue, 30 Aug 2022 13:34:41 +0200
+
 inetutils (2:2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
2022-08-30 13:33:33.0 +0200
@@ -0,0 +1,59 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c | 21 +
+ 2 files changed, 30 insertions(+)
+
+diff --git a/ftp/ftp.

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Simon McVittie]

On Thu, 25 Aug 2022 at 13:14:33 -0500, Gunnar Wolf wrote:
> Simon McVittie dijo [Thu, Aug 25, 2022 at 11:19:30AM +0100]:
> > Is armel a realistic candidate for being a Debian 12 release
> > architecture?
> 
> I do not feel armel systems are hard to come by, nor marginal in the
> amount of users they have. Yes, running a GNOME desktop on them might
> be a Very Bad Idea (if at all possible)...  But they are very good
> non-interactive purposes.

Your vote for retaining armel as a release architecture is noted (but
that decision is not up to me - it's up to the release team, with input
from the ARM porters who are responsible for doing the work to keep the
port alive).

If armel is a candidate for being a release architecture, then I think
that leaves two-and-a-half options:

1. task-gnome-desktop is uninstallable on this architecture
  1a. or Bastien's suggestion: task-gnome-desktop is installable on this
  architecture, but the preinst fails on baseline CPUs
2. task-gnome-desktop installs something that is not the full GNOME
   desktop on this architecture

I would personally prefer 1., but last time I tried this (for s390x),
it was blocked by the release machinery not allowing any task package to
be uninstallable on any release architecture, even if the task doesn't
really make sense there. So I am going to work towards 2., unless the
release team tells me that 1. can be made to work.

On Sat, 27 Aug 2022 at 15:41:44 +, Bastien Roucariès wrote:
> adding support to armv6-support will help here

I spoke to an ARM porter (Peter Green) at the weekend, and based on what
he said, it would probably have to be armv7-support: if I'm understanding
correctly, ARMv6 includes *some* atomic instructions, but they are not
the ones that mozjs wants to invoke from inline assembler and its JIT,
and are not really safe to use on ARMv7 CPUs.

Are you suggesting that mozjs102 should add a Build-Depends and
(Pre-?)Depends on armv7-support [armel], and override the compiler
defaults on armel to build with something like -march=armv7?

That doesn't seem very honest, or very efficient: we'd be compiling an
ARMv7 binary as part of what is in theory our ARMv5 port, knowing that
anyone who could successfully run it would be better served by installing
libmozjs-102-0:armhf instead.

For non-baseline i386 extensions (MMX, SSE, SSE2), isa-support has two
justifications for existing:

- there is a reasonably common class of CPU that is not supported by our
  next-higher-baseline port but would benefit from the non-baseline
  extension (CPUs from the Pentium II/III/IV era, which have SSE2 but are
  still only 32-bit, and cannot run amd64 binaries);
- there are commonly-used proprietary binaries which cannot simply be
  recompiled for the next-higher-baseline ABI, and require libraries with
  the older ABI for their dependencies (Linux i386 binary-only games etc.,
  and 32-bit Windows binary-only programs running under Wine)

Neither of those justifications seems to me like it really applies to the
boundary between armel and armhf, unless there is a widespread class of
CPU that has all the mandatory ARMv7 instructions (including the atomic
operations that mozjs wants), but lacks VFP hardfloat support.

smcv

Re: uncoordinated abseil transition ( was: Re: Accepted abseil 0~20220623.0-1 (source amd64) into unstable, unstable)

[Benjamin Barenblat]

On Tuesday, August 30, 2022, at  8:34 AM +0200, Sebastian Ramacher wrote:
> Reverse dependencies of abseil are also part of the ongoing Gnome 3 /
> libsoup3 / etc transition. As I'd like to avoid to getting that blocked
> for to long, I'd appreciate a quick fix for the ppc64el FTBFS bug of
> abseil. Do you have an estimate when you'd be able to work on the bug?

I'll do it today.

Benjamin

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Paul Gevers]

Hi Simon, all,

On 30-08-2022 14:48, Simon McVittie wrote:

If armel is a candidate for being a release architecture, then I think
that leaves two-and-a-half options:


In the last couple of releases, we have been bad at taking decisions on 
this front, so lets assume it is (although this issue is another push in 
the direction of dropping).



1. task-gnome-desktop is uninstallable on this architecture


I have briefly checked with kibi on IRC and we currently think this is 
acceptable.



   1a. or Bastien's suggestion: task-gnome-desktop is installable on this
   architecture, but the preinst fails on baseline CPUs
2. task-gnome-desktop installs something that is not the full GNOME
desktop on this architecture

I would personally prefer 1., but last time I tried this (for s390x),
it was blocked by the release machinery not allowing any task package to
be uninstallable on any release architecture, even if the task doesn't
really make sense there. So I am going to work towards 2., unless the
release team tells me that 1. can be made to work.


So, it'd say, let's try if we can do that (1). Looking at bug #906016 
IIUC it was mostly stalled on some input from our side, not really 
because of machinery being unpersuasive.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018800: buster-pu: package inetutils/2:1.9.4-7+deb10u2

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

Hi!

This is the counterpart to #1018744 but for buster.

[ Reason ]

This fixes three pending security issue, that the security team (CCed)
would prefer to see handled as normal oldstable updates.

(This is the same set of changes as the bullseye version, plus a couple
of patches from upstream for CVE-2019-0053, that are missing in that
version.)

[ Impact ]

All changes are security related, mostly buffer overflows, that can at
least cause crashes and DoS.

[ Tests ]

The same tests as the ones for bullseye in #1018744 were used here and
the issues could be reproduced before, and not any more after the
patched version.

[ Risks ]

Same risks as the version for bullseye.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

  * Security fixes for telnet client:
- Validate supplied environment variables.
- Check for buffer overflows when processing telnet protocol messages.
- Add checks for option reply parsing limits causing buffer
  overflow induced crashes due to long option values.
- Fix infinite loop causing a stack exhaustion induced crash due to
  malicious server commands.
Fixes CVE-2019-0053. Closes: #945861
  * Fix inetutils-ftp security bug trusting FTP PASV responses.
Fixes CVE-2021-40491. Closes: #993476
  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
adapted by Erik Auerswald .
Fixes CVE-2022-39028.

[ Other info ]

None.

Thanks,
Guillem
diff -Nru inetutils-1.9.4/debian/changelog inetutils-1.9.4/debian/changelog
--- inetutils-1.9.4/debian/changelog2020-09-18 20:06:42.0 +0200
+++ inetutils-1.9.4/debian/changelog2022-08-31 00:58:35.0 +0200
@@ -1,3 +1,23 @@
+inetutils (2:1.9.4-7+deb10u2) buster; urgency=medium
+
+  * Security fixes for telnet client:
+- Validate supplied environment variables.
+- Check for buffer overflows when processing telnet protocol messages.
+- Add checks for option reply parsing limits causing buffer
+  overflow induced crashes due to long option values.
+- Fix infinite loop causing a stack exhaustion induced crash due to
+  malicious server commands.
+Fixes CVE-2019-0053. Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Wed, 31 Aug 2022 00:58:35 +0200
+
 inetutils (2:1.9.4-7+deb10u1) buster; urgency=medium
 
   * CVE-2020-10188 (Closes: #956084)
diff -Nru 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  1970-01-01 01:00:00.0 +0100
+++ 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  2022-08-31 00:58:35.0 +0200
@@ -0,0 +1,54 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c |   21 +
+ 1 file changed, 21 insertions(+)
+
+--- a/ftp/ftp.c
 b/ftp/ftp.c
+@@ -1357,6 +1357,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) &data_addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) | 
h[3]);
+   }
++  if (data_addr_sa4->sin_addr.s_addr
++  != ((struct sockaddr_in *) &hisctladdr)->sin_addr.s_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv4 */
+ else /* IPv6 */
+   {
+@@ -1387,6 +1394,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8) 
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] << 
8) | h[15]);
+   }
++  if (data_addr_sa6->sin6_addr.s6_addr
++  != ((struct sockaddr_i

Re: uncoordinated abseil transition ( was: Re: Accepted abseil 0~20220623.0-1 (source amd64) into unstable, unstable)

[Benjamin Barenblat]

On Tuesday, August 30, 2022, at  8:34 AM +0200, Sebastian Ramacher wrote:
> Reverse dependencies of abseil are also part of the ongoing Gnome 3 /
> libsoup3 / etc transition. As I'd like to avoid to getting that blocked
> for to long, I'd appreciate a quick fix for the ppc64el FTBFS bug of
> abseil. Do you have an estimate when you'd be able to work on the bug?

On Tuesday, August 30, 2022, at 10:57 AM -0400, Benjamin Barenblat wrote:
> I'll do it today.

I had a look at the failing test today, and it appears fairly subtle. I
think it involves picking the correct memory ordering for atomics on
weak-memory-model systems, which I’ve never been great at. I’ll keep
investigating, but in the meantime, I’ve uploaded 0~20220623.0-2, which
just disables the problematic test. This should clear up the FTBFS.
Please let me know if there’s anything else I can do!

Benjamin

Bug#1018076: transition: gjs and gnome-shell likely to be removed from armel

[Paul Gevers]

Hi,

On 30-08-2022 22:20, Paul Gevers wrote:
[...]

For avoidance of doubt, I didn't ACK or NACK the transition. I just 
wanted to answer Simon's question about the course of solutions.


Paul


OpenPGP_signature
Description: OpenPGP digital signature