Bug#1082511: micropython: CVE-2024-8946 CVE-2024-8947 CVE-2024-8948

[Salvatore Bonaccorso]

Source: micropython
Version: 1.22.1+ds-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for micropython.

CVE-2024-8946[0]:
| A vulnerability was found in MicroPython 1.23.0. It has been
| classified as critical. Affected is the function mp_vfs_umount of
| the file extmod/vfs.c of the component VFS Unmount Handler. The
| manipulation leads to heap-based buffer overflow. It is possible to
| launch the attack remotely. The exploit has been disclosed to the
| public and may be used. The name of the patch is
| 29943546343c92334e8518695a11fc0e2ceea68b. It is recommended to apply
| a patch to fix this issue. In the VFS unmount process, the
| comparison between the mounted path string and the unmount requested
| string is based solely on the length of the unmount string, which
| can lead to a heap buffer overflow read.


CVE-2024-8947[1]:
| A vulnerability was found in MicroPython 1.22.2. It has been
| declared as critical. Affected by this vulnerability is an unknown
| functionality of the file py/objarray.c. The manipulation leads to
| use after free. The attack can be launched remotely. The complexity
| of an attack is rather high. The exploitation appears to be
| difficult. Upgrading to version 1.23.0 is able to address this
| issue. The identifier of the patch is
| 4bed614e707c0644c06e117f848fa12605c711cd. It is recommended to
| upgrade the affected component. In micropython objarray component,
| when a bytes object is resized and copied into itself, it may
| reference memory that has already been freed.


CVE-2024-8948[2]:
| A vulnerability was found in MicroPython 1.23.0. It has been rated
| as critical. Affected by this issue is the function mpz_as_bytes of
| the file py/objint.c. The manipulation leads to heap-based buffer
| overflow. The attack may be launched remotely. The exploit has been
| disclosed to the public and may be used. The patch is identified as
| 908ab1ceca15ee6fd0ef82ca4cba770a3ec41894. It is recommended to apply
| a patch to fix this issue. In micropython objint component,
| converting zero from int to bytes leads to heap buffer-overflow-
| write at mpz_as_bytes.


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-2024-8946
https://www.cve.org/CVERecord?id=CVE-2024-8946
[1] https://security-tracker.debian.org/tracker/CVE-2024-8947
https://www.cve.org/CVERecord?id=CVE-2024-8947
[2] https://security-tracker.debian.org/tracker/CVE-2024-8948
https://www.cve.org/CVERecord?id=CVE-2024-8948

Regards,
Salvatore

Bug#1079684: still issues in linux 6.1.106-3

[Salvatore Bonaccorso]

Hi David, hi Emanuel,

On Wed, Sep 18, 2024 at 08:29:54AM +0200, David Prévot wrote:
> Control: clone -1 -2
> Control: reopen -2
> Control: found -2 linux/6.1.106-3
> Control: retitle -2 Performance issues on VM (virtio)
> 
> Hi,
> 
> Le Mon, Sep 16, 2024 at 11:37:07AM +, Kocher Emanuel, Bedag a écrit :
> […]
> > We still see issues with linux/6.1.106-3 in combination with virtio.
> 
> Thanks for the feedback.
> 
> > Network performance is down to ~4 Mb/s measured with iperf3 instead of 
> > ~8 Gb/s (with linux/6.1.99-1 respectively 6.1.0-23-amd64). It is 
> > reproducible and booting the previous kernel resolves the issue.
> 
> Our network team also noticed performance issues, roughly 20 to 30%
> increase speed on packages download once we reverted to 6.1.0-23-amd64
> on a mirror we host. Not sure it’s exactly the same issue as the one
> initially reported, hence the clone, but I agree there is still an issue
> with the current stable kernel.

Thanks for reporting back. I will try to reproduce it so we can test
against newer 6.1.y kernels as well. Do you have reproducers available
to show it?

Regards,
Salvatore

Bug#1068782: libesmtp: diff for NMU version 1.1.0-3.2

[Salvatore Bonaccorso]

Control: tags 1068782 + pending
Control: tags 1071322 + patch
Control: tags 1071322 + pending


Hi Jeremy,

I've prepared an NMU for libesmtp (versioned as 1.1.0-3.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

I see it as intermediate solution to get the packages back into
testing. Whenever upstream wakes up, make sense to re-evaluate the
patches and drop them in favour of upstreams.

Regards,
Salvatore
diff -Nru libesmtp-1.1.0/debian/changelog libesmtp-1.1.0/debian/changelog
--- libesmtp-1.1.0/debian/changelog	2023-08-19 12:04:32.0 +0200
+++ libesmtp-1.1.0/debian/changelog	2024-09-16 21:36:36.0 +0200
@@ -1,3 +1,16 @@
+libesmtp (1.1.0-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Michael Hudson-Doyle ]
+  * d/patches/time64: cast time_t values to long long before passing to
+*printf functions (code storing time_t values in void* variables will
+still break in 2038). (Closes: #1068782)
+  * d/patches/default-source: define _DEFAULT_SOURCE to get access to
+prototype of strlcpy. (Closes: #1071322)
+
+ -- Salvatore Bonaccorso   Mon, 16 Sep 2024 21:36:36 +0200
+
 libesmtp (1.1.0-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libesmtp-1.1.0/debian/patches/default-source libesmtp-1.1.0/debian/patches/default-source
--- libesmtp-1.1.0/debian/patches/default-source	1970-01-01 01:00:00.0 +0100
+++ libesmtp-1.1.0/debian/patches/default-source	2024-09-16 21:36:36.0 +0200
@@ -0,0 +1,10 @@
+--- a/meson.build
 b/meson.build
+@@ -30,6 +30,7 @@
+ 
+ cflags = [
+   '-D_POSIX_C_SOURCE=200809L',
++  '-D_DEFAULT_SOURCE',
+ ]
+ 
+ cflags_warnings = [
diff -Nru libesmtp-1.1.0/debian/patches/series libesmtp-1.1.0/debian/patches/series
--- libesmtp-1.1.0/debian/patches/series	2023-08-19 12:04:32.0 +0200
+++ libesmtp-1.1.0/debian/patches/series	2024-09-16 21:36:36.0 +0200
@@ -1 +1,3 @@
 meson-build-soname
+time64
+default-source
diff -Nru libesmtp-1.1.0/debian/patches/time64 libesmtp-1.1.0/debian/patches/time64
--- libesmtp-1.1.0/debian/patches/time64	1970-01-01 01:00:00.0 +0100
+++ libesmtp-1.1.0/debian/patches/time64	2024-09-16 21:36:36.0 +0200
@@ -0,0 +1,16 @@
+--- a/headers.c
 b/headers.c
+@@ -170,11 +170,11 @@
+ {
+ #ifdef HAVE_GETTIMEOFDAY
+   if (gettimeofday (&tv, NULL) != -1) /* This shouldn't fail ... */
+-	snprintf (buf, sizeof buf, "%ld.%ld.%d@%s", tv.tv_sec, tv.tv_usec,
++	  snprintf (buf, sizeof buf, "%lld.%lld.%d@%s", (long long)tv.tv_sec, (long long)tv.tv_usec,
+ 		  getpid (), message->session->localhost);
+   else /* ... but if it does fall back to using time() */
+ #endif
+-  snprintf (buf, sizeof buf, "%ld.%d@%s", time (NULL),
++  snprintf (buf, sizeof buf, "%lld.%d@%s", (long long)time (NULL),
+ 		getpid (), message->session->localhost);
+   message_id = buf;
+ }

Bug#1081792: opennds: CVE-2024-25763

[Salvatore Bonaccorso]

Hi Petter,

On Sun, Sep 15, 2024 at 10:07:00AM +0200, Petter Reinholdtsen wrote:
> 
> The original upstream issue was closed 2024-02-28.  The CVE is mentioned
> in https://github.com/openNDS/openNDS/issues/600 >, closed
> 2024-05-29.
> 
> I thus suspect a new upstream version will fix this issue.

Yes it is fixed in 10.3.0 upstream.

Regards,
Salvatore

Bug#1081792: opennds: CVE-2024-25763

[Salvatore Bonaccorso]

Source: opennds
Version: 10.2.0+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/openNDS/openNDS/issues/571
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for opennds.

CVE-2024-25763[0]:
| openNDS 10.2.0 is vulnerable to Use-After-Free via
| /openNDS/src/auth.c.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-25763
https://www.cve.org/CVERecord?id=CVE-2024-25763
[1] https://github.com/openNDS/openNDS/issues/571

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1081791: wolfssl: CVE-2024-5814

[Salvatore Bonaccorso]

Source: wolfssl
Version: 5.7.0-0.3
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/wolfSSL/wolfssl/pull/7619
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2024-5814[0]:
| A malicious TLS1.2 server can force a TLS1.3 client with downgrade
| capability to use a ciphersuite that it did not agree to and achieve
| a successful connection. This is because, aside from the extensions,
| the client was skipping fully parsing the server hello.
| https://doi.org/10.46586/tches.v2024.i1.457-500

Note, I'm filling this with RC severity as all the recent uploads were
done as NMU. Is wolfssl right now ok to be released for upcoming
trixie or should we need to keep it out?

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5814
https://www.cve.org/CVERecord?id=CVE-2024-5814
[1] https://github.com/wolfSSL/wolfssl/pull/7619

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1081790: wolfssl: CVE-2024-5288

[Salvatore Bonaccorso]

Source: wolfssl
Version: 5.7.0-0.3
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/wolfSSL/wolfssl/pull/7416
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2024-5288[0]:
| An issue was discovered in wolfSSL before 5.7.0. A safe-error attack
| via Rowhammer, namely FAULT+PROBE, leads to ECDSA key disclosure.
| When WOLFSSL_CHECK_SIG_FAULTS is used in signing operations with
| private ECC keys,  such as in server-side TLS connections, the
| connection is halted if any fault occurs. The success rate in a
| certain amount of connection requests can be processed via an
| advanced technique for ECDSA key recovery.

Note the official CVE description from MITRE seems to not cover the
where the issue was fixed. According to upstream and merged commits
this should be in 5.7.2 only.

Note, I'm filling this with RC severity as all the recent uploads were
done as NMU. Is wolfssl right now ok to be released for upcoming
trixie or should we need to keep it out?

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5288
https://www.cve.org/CVERecord?id=CVE-2024-5288
[1] https://github.com/wolfSSL/wolfssl/pull/7416

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1081789: wolfssl: CVE-2024-1544

[Salvatore Bonaccorso]

Source: wolfssl
Version: 5.7.0-0.3
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/wolfSSL/wolfssl/pull/7020
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2024-1544[0]:
| Generating the ECDSA nonce k samples a random number r and then
| truncates this randomness with a modular reduction mod n where n is
| the  order of the elliptic curve. Meaning k = r mod n. The division
| used  during the reduction estimates a factor q_e by dividing the
| upper two  digits (a digit having e.g. a size of 8 byte) of r by the
| upper digit of  n and then decrements q_e in a loop until it has the
| correct size.  Observing the number of times q_e is decremented
| through a control-flow  revealing side-channel reveals a bias in the
| most significant bits of  k. Depending on the curve this is either a
| negligible bias or a  significant bias large enough to reconstruct k
| with lattice reduction  methods. For SECP160R1, e.g., we find a bias
| of 15 bits.

Note, I'm filling this with RC severity as all the recent uploads were
done as NMU. Is wolfssl right now ok to be released for upcoming
trixie or should we need to keep it out?

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-1544
https://www.cve.org/CVERecord?id=CVE-2024-1544
[1] https://github.com/wolfSSL/wolfssl/pull/7020

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1081788: wolfssl: CVE-2024-5991

[Salvatore Bonaccorso]

Source: wolfssl
Version: 5.7.0-0.3
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/wolfSSL/wolfssl/pull/7604
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2024-5991[0]:
| In function MatchDomainName(), input param str is treated as a NULL
| terminated string despite being user provided and unchecked.
| Specifically, the function X509_check_host() takes in a pointer and
| length to check against, with no requirements that it be NULL
| terminated. If a caller was attempting to do a name check on a non-
| NULL terminated buffer, the code would read beyond the bounds of the
| input array until it found a NULL terminator.This issue affects
| wolfSSL: through 5.7.0.

Note, I'm filling this with RC severity as all the recent uploads were
done as NMU. Is wolfssl right now ok to be released for upcoming
trixie or should we need to keep it out?

If you fix the vulnerability please also make sure to include the
raCVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5991
https://www.cve.org/CVERecord?id=CVE-2024-5991
[1] https://github.com/wolfSSL/wolfssl/pull/7604

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1067284: closing 1067018, closing 1067284

[Salvatore Bonaccorso]

close 1067018 
close 1067284 
thanks

These can be now be closed with the removal of the binary packages for armel
and armhf.

Bug#1067018: Bug#1067284: Bug#1067018: lnav: FTBFS on arm{el,hf}: test failures

[Salvatore Bonaccorso]

Hi Chris,

On Sat, Sep 14, 2024 at 01:26:07AM +0200, Chris Hofstaedtler wrote:
> Hello Salvatore,
> 
> On Fri, Sep 13, 2024 at 08:47:27PM +0200, Salvatore Bonaccorso wrote:
> > Unfortunately the 64bit time transition for armhf and armel is still
> > blocking us to get it back into testing.
> > 
> > I have it building on all other architectures, but as long we do can
> > get it back for armel and armhf we are out :(
> 
> Removing lnav from armel, armhf may be a way forward. I somewhat
> doubt that the people interested in 32-bit arm will help here, as
> they are probably not interested in packages as lnav.

Thanks. I have requested to ftp-masters that lnav get remove for armel
and armhf.
> 
> > They are tests failing, but I'm reluctant to disable them because they
> > might show for real that lnav is not working since the time transition
> > on armel/armhf on those architectures anymore.
> 
> I agree the tests should not be disabled there.

Thanks for looking into this issue, I really much appreiciated the
feedback you.

Regards,
Salvatore

Bug#1081683: criu: CRIU restore fails due to segmentation fault with libc6 2.36-9+deb12u8

[Salvatore Bonaccorso]

Source: criu
Version: 3.17.1-2
Severity: grave
Forwarded: https://github.com/checkpoint-restore/criu/issues/2477
X-Debbugs-Cc: car...@debian.org
Control: tags -1 + bookworm

As reported in, in stable, with glibc 2.36-9+deb12u8 criu restore
fails.

Regards,
Salvatore

Bug#1067018: lnav: FTBFS on arm{el,hf}: test failures

[Salvatore Bonaccorso]

Control: tags 1067018 + help
Control: tags 1067284 + help

Hi Michael,

On Fri, Sep 13, 2024 at 02:20:40PM +0200, Michael Prokop wrote:
> Hi!
> 
> * Salvatore Bonaccorso [Fri Apr 19, 2024 at 10:31:52PM +0200]:
> > FWIW, I will try to work on the new available upstream version in the
> > next days and see if the two RC bugs on lnav can be addressed along.
> > 
> > it does not make sense to investigate the testsuite failure right now
> > without rebasing to the new version.
> 
> Friendly maintainer ping :) Any news on this, Salvatore?
> 
> I see that you uploaded 0.12.2-1~exp2 to experimental, though lnav
> is missing in Debian/testing now due to the RC bugs, and it would be
> nice if lnav could make its way to trixie. :)

Unfortunately the 64bit time transition for armhf and armel is still
blocking us to get it back into testing.

I have it building on all other architectures, but as long we do can
get it back for armel and armhf we are out :(

I'm tagging the bugs as 'help' so maybe it gets bit more traction,
because believe me I'm more than intersted to not see trixie releases
without lnav :)

They are tests failing, but I'm reluctant to disable them because they
might show for real that lnav is not working since the time transition
on armel/armhf on those architectures anymore.

If you have ideas I would glady hear how to proceed.

Regards,
Salvatore

Bug#1078970: fence-agents: CVE-2024-5651

[Salvatore Bonaccorso]

On Fri, Sep 13, 2024 at 11:35:12PM +0900, wf...@debian.org wrote:
> At 2024-08-18 21:19 Salvatore Bonaccorso wrote:
> 
> > The following vulnerability was published for fence-agents.
> > 
> > CVE-2024-5651[0]:
> > | A flaw was found in fence agents that rely on SSH/Telnet. This
> > | vulnerability can allow a Remote Code Execution (RCE) primitive by
> > | supplying an arbitrary command to execute in the --ssh-
> > | path/--telnet-path arguments. A low-privilege user, for example, a
> > | user with developer access, can create a specially crafted
> > | FenceAgentsRemediation for a fence agent supporting  --ssh-
> > | path/--telnet-path arguments to execute arbitrary commands on the
> > | operator's pod. This RCE leads to a privilege escalation, first as
> > | the service account running the operator, then to another service
> > | account with cluster-admin privileges.
> > 
> > Unfortunately, at time of writing this bugreport, the only reference I
> > have found for this CVE is the one linked in the CVE entry is [1].
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2290540
> 
> That Bugzilla entry references
> https://access.redhat.com/errata/RHSA-2024:5453, which further references
> https://access.redhat.com/security/cve/CVE-2024-5651, which states:
> "This vulnerability is specific to the Fence Agents Remediation operator
> and does not affect fence-agents itself."
> So I don't think this issue affects Debian.

Thank you both for the analysis. I do not remember if that was written
same when I filled the but, thus as well the explicit wording, but I
think then we can go ahead and close this bug.

Regards,
Salvatore

Bug#1081561: php-twig: CVE-2024-45411

[Salvatore Bonaccorso]

Source: php-twig
Version: 3.8.0-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.5.1-1

Hi,

The following vulnerability was published for php-twig.

CVE-2024-45411[0]:
| Twig is a template language for PHP. Under some circumstances, the
| sandbox security checks are not run which allows user-contributed
| templates to bypass the sandbox restrictions. This vulnerability is
| fixed in 1.44.8, 2.16.1, and 3.14.0.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-45411
https://www.cve.org/CVERecord?id=CVE-2024-45411
[1] https://github.com/twigphp/Twig/security/advisories/GHSA-6j75-5wfj-gh66
[2] 
https://github.com/twigphp/Twig/commit/11f68e2aeb526bfaf638e30d4420d8a710f3f7c6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1081560: ruby-saml: CVE-2024-45409

[Salvatore Bonaccorso]

Source: ruby-saml
Version: 1.15.0-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.13.0-1

Hi,

The following vulnerability was published for ruby-saml.

CVE-2024-45409[0]:
| The Ruby SAML library is for implementing the client side of a SAML
| authorization. Ruby-SAML in <= 12.2 and 1.13.0 <= 1.16.0 does not
| properly verify the signature of the SAML Response. An
| unauthenticated attacker with access to any signed saml document (by
| the IdP) can thus forge a SAML Response/Assertion with arbitrary
| contents. This would allow the attacker to log in as arbitrary user
| within the vulnerable system. This vulnerability is fixed in 1.17.0
| and 1.12.3.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-45409
https://www.cve.org/CVERecord?id=CVE-2024-45409
[1] 
https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2
[2] 
https://github.com/SAML-Toolkits/ruby-saml/commit/1ec5392bc506fe43a02dbb66b68741051c5ffeae
[3] 
https://github.com/SAML-Toolkits/ruby-saml/commit/4865d030cae9705ee5cdb12415c654c634093ae7

Regards,
Salvatore

Bug#1078408: autofs: diff for NMU version 5.1.9-1.2

[Salvatore Bonaccorso]

Control: tags 1078408 + pending

Dear maintainer,

I've prepared an NMU for autofs (versioned as 5.1.9-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru autofs-5.1.9/debian/changelog autofs-5.1.9/debian/changelog
--- autofs-5.1.9/debian/changelog	2024-03-10 13:06:17.0 +0100
+++ autofs-5.1.9/debian/changelog	2024-09-11 20:56:38.0 +0200
@@ -1,3 +1,11 @@
+autofs (5.1.9-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix incompatible function pointer types in cyrus-sasl module (Closes:
+#1078408)
+
+ -- Salvatore Bonaccorso   Wed, 11 Sep 2024 20:56:38 +0200
+
 autofs (5.1.9-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru autofs-5.1.9/debian/patches/autofs-5.1.9-Fix-incompatible-function-pointer-types.patch autofs-5.1.9/debian/patches/autofs-5.1.9-Fix-incompatible-function-pointer-types.patch
--- autofs-5.1.9/debian/patches/autofs-5.1.9-Fix-incompatible-function-pointer-types.patch	1970-01-01 01:00:00.0 +0100
+++ autofs-5.1.9/debian/patches/autofs-5.1.9-Fix-incompatible-function-pointer-types.patch	2024-09-11 20:56:38.0 +0200
@@ -0,0 +1,49 @@
+From: Florian Weimer 
+Date: Mon, 18 Dec 2023 13:48:18 +0100
+Subject: autofs-5.1.9 - Fix incompatible function pointer types in cyrus-sasl
+ module
+Origin: https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/commit?id=b7ff971bb8aa3fc609bb531ddc4c2ce56226383f
+Bug-Debian: https://bugs.debian.org/1078408
+
+Add casts to SASL callbacks to avoid incompatible-pointer-types
+errors.  Avoids a build failure with stricter compilers.
+
+Signed-off-by: Florian Weimer 
+Signed-off-by: Ian Kent 
+---
+ CHANGELOG|  2 ++
+ modules/cyrus-sasl.c | 14 +++---
+ 2 files changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/modules/cyrus-sasl.c b/modules/cyrus-sasl.c
+index e742eaf8ebe6..78b77942ba3e 100644
+--- a/modules/cyrus-sasl.c
 b/modules/cyrus-sasl.c
+@@ -109,17 +109,17 @@ static int getpass_func(sasl_conn_t *, void *, int, sasl_secret_t **);
+ static int getuser_func(void *, int, const char **, unsigned *);
+ 
+ static sasl_callback_t callbacks[] = {
+-	{ SASL_CB_USER, &getuser_func, NULL },
+-	{ SASL_CB_AUTHNAME, &getuser_func, NULL },
+-	{ SASL_CB_PASS, &getpass_func, NULL },
++	{ SASL_CB_USER, (int(*)(void)) &getuser_func, NULL },
++	{ SASL_CB_AUTHNAME, (int(*)(void)) &getuser_func, NULL },
++	{ SASL_CB_PASS, (int(*)(void)) &getpass_func, NULL },
+ 	{ SASL_CB_LIST_END, NULL, NULL },
+ };
+ 
+ static sasl_callback_t debug_callbacks[] = {
+-	{ SASL_CB_LOG, &sasl_log_func, NULL },
+-	{ SASL_CB_USER, &getuser_func, NULL },
+-	{ SASL_CB_AUTHNAME, &getuser_func, NULL },
+-	{ SASL_CB_PASS, &getpass_func, NULL },
++	{ SASL_CB_LOG, (int(*)(void)) &sasl_log_func, NULL },
++	{ SASL_CB_USER, (int(*)(void)) &getuser_func, NULL },
++	{ SASL_CB_AUTHNAME, (int(*)(void)) &getuser_func, NULL },
++	{ SASL_CB_PASS, (int(*)(void)) &getpass_func, NULL },
+ 	{ SASL_CB_LIST_END, NULL, NULL },
+ };
+ 
+-- 
+2.45.2
+
diff -Nru autofs-5.1.9/debian/patches/series autofs-5.1.9/debian/patches/series
--- autofs-5.1.9/debian/patches/series	2024-02-11 18:45:01.0 +0100
+++ autofs-5.1.9/debian/patches/series	2024-09-11 20:56:38.0 +0200
@@ -11,3 +11,4 @@
 spelling-error-fixes.patch
 fix-lookup-ldap-crash.patch
 fix-nfs4-mounts-in-auto-net.patch
+autofs-5.1.9-Fix-incompatible-function-pointer-types.patch

Bug#1059300: closing 1059300

[Salvatore Bonaccorso]

close 1059300 7.2.1+dfsg-1
thanks

Bug#1079394: linux-image-6.10.6-amd64: causes cifs regression, flatpak & ostree signature corruption

[Salvatore Bonaccorso]

Hi

On Sat, Aug 24, 2024 at 01:08:01AM -0700, Forest wrote:
> After further testing today, that commit also seems to be (intermittently)
> causing ffmpeg and mkvmerge to write corrupt files to cifs mounts.
> 
> 
> On Fri, 23 Aug 2024 22:13:07 +0200, Salvatore Bonaccorso wrote:
> 
> >Since you identified this as upstream regression including the
> >breaking commit, can you please report this upstream (and please do
> >keep us in the loop).
> 
> That is my plan. Last time I reported a bug to the cifs team, it was
> ignored, but perhaps I'll have more luck through the additional email
> addresses you provided. Thanks for those.
> 
> 
> In the meantime, I'm in an awkward position on Debian: The Stable kernel is
> too old for my GPU, and both Testing and Unstable now have kernels with this
> data-corrupting bug.
> 
> Looks like I'm stuck with custom kernel builds until this is sorted out.
> 6.9.12 doesn't have the bug, but it's labeled EOL on kernel.org, which I
> think means no more security updates. I guess I'll have to try the 6.6
> branch.

AFIU, this should be fixed with c26096ee0278 ("mm: Fix
filemap_invalidate_inode() to use invalidate_inode_pages2_range()")
upstream, correct?

Regards,
Salvatore

Bug#1071322: Bug#1068782: Bug#1071322: News on those issues?

[Salvatore Bonaccorso]

Hi Jeremy,

On Thu, Aug 01, 2024 at 07:22:34AM +0200, Salvatore Bonaccorso wrote:
> Hi Jeremy,
> 
> On Sun, Jun 30, 2024 at 02:47:41PM +0200, Salvatore Bonaccorso wrote:
> > Hi Jeremy,
> > 
> > On Mon, Jun 17, 2024 at 04:31:04PM -0400, Jeremy T. Bouse wrote:
> > > Upstream had been MIA for years; its last release was in 2010. It appears
> > > he has finally returned, but I haven't had time to deal with the new
> > > version that was released two weeks ago.
> > 
> > Thanks for the answer. 
> > 
> > Question: will you find time to deal with those issues, before 17th of
> > upciming month? Because then libesmtp and reverse dependencies will be
> > removed otherwise from trixie.
> 
> FWIW, libesmtp and its reverse dependencies are now removed from
> testing, so I'm pretty much interested seeing it in trixie. 
> 
> Upstream has not responded to the Ubuntu proposed patches in
> https://github.com/libesmtp/libESMTP/issues/21 .
> 
> Can you try to approach upstream to see if upstream can deal with the
> issue in their preferred way and we can cherry-pick the fixes as
> needed?

Any news here? Currently libesmtp and reverse dependencies are out of
Debian trixie/testing and the package needs to come back before the
freeze.

Regards,
Salvatore

Bug#1076955: notfound 1076955 in 1.1.0, found 1076955 in 1.1.0~git20220701.1d4e111-0.5, closing 1076955 ...

[Salvatore Bonaccorso]

notfound 1076955 1.1.0
found 1076955 1.1.0~git20220701.1d4e111-0.5
close 1076955 1.1.0~git20220701.1d4e111-1
tags 1076955 + security
thanks

Bug#1078274: clamav: FTBFS: clamscan/assorted_test.py::TC::test_pe_cert_trust FAILED

[Salvatore Bonaccorso]

Hi,

On Fri, Sep 06, 2024 at 12:49:25AM +0200, Santiago Vila wrote:
> El 4/9/24 a las 19:52, Sebastian Andrzej Siewior escribió:
> > On 2024-09-01 22:02:27 [+0200], Santiago Vila wrote:
> > > Could we please fix it in bookworm as well?
> > > (packages in stable must build in stable)
> > 
> > I plan to prepare 1.0.7 as pu this weekend.
> 
> Note: There is now a security bug (#1080962) so
> fixing only the ftbfs problem would probably
> not make much sense right now.
> 
> I hope you can coordinate with Security Team.

As Sebastian is planning via pu is perfectly fine. clamav updates are
released via point releases with stable-updates as needed in advance.

Regards,
Salvatore

Bug#1080964: aardvark-dns: CVE-2024-8418

[Salvatore Bonaccorso]

Source: aardvark-dns
Version: 1.12.1-2
Severity: grave
Tags: security upstream
Forwarded: https://github.com/containers/aardvark-dns/issues/500
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for aardvark-dns.

CVE-2024-8418[0]:
| A flaw was found in Aardvark-dns versions 1.12.0 and 1.12.1. They
| contain a denial of service vulnerability due to serial processing
| of TCP DNS queries. This flaw allows a malicious client to keep a
| TCP connection open indefinitely, causing other DNS queries to time
| out and resulting in a denial of service for all other containers
| using aardvark-dns.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-8418
https://www.cve.org/CVERecord?id=CVE-2024-8418
[1] https://github.com/containers/aardvark-dns/issues/500
[2] https://github.com/containers/aardvark-dns/pull/503

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1080962: clamav: CVE-2024-20505 CVE-2024-20506

[Salvatore Bonaccorso]

Source: clamav
Version: 1.3.1+dfsg-5
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.0.5+dfsg-1~deb12u1
Control: found -1 0.103.10+dfsg-0+deb11u1

Hi,

The following vulnerabilities were published for clamav.

CVE-2024-20505[0]:
| A vulnerability in the PDF parsing module of Clam AntiVirus (ClamAV)
| versions 1.4.0, 1.3.2 and prior versions, all 1.2.x versions, 1.0.6
| and prior versions, all 0.105.x versions, all 0.104.x versions, and
| 0.103.11 and all prior versions could allow an unauthenticated,
| remote attacker to cause a denial of service (DoS) condition on an
| affected device.The vulnerability is due to an out of bounds
| read. An attacker could exploit this vulnerability by submitting a
| crafted PDF file to be scanned by ClamAV on an affected device. An
| exploit could allow the attacker to terminate the scanning process.


CVE-2024-20506[1]:
| A vulnerability in the ClamD service module of Clam AntiVirus
| (ClamAV) versions 1.4.0, 1.3.2 and prior versions, all 1.2.x
| versions, 1.0.6 and prior versions, all 0.105.x versions, all
| 0.104.x versions, and 0.103.11 and all prior versions could allow an
| authenticated, local attacker to corrupt critical system files.
| The vulnerability is due to allowing the ClamD process to write to
| its log file while privileged without checking if the logfile has
| been replaced with a symbolic link. An attacker could exploit this
| vulnerability if they replace the ClamD log file with a symlink to a
| critical system file and then find a way to restart the ClamD
| process. An exploit could allow the attacker to corrupt a critical
| system file by appending ClamD log messages after restart.


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-2024-20505
https://www.cve.org/CVERecord?id=CVE-2024-20505
[1] https://security-tracker.debian.org/tracker/CVE-2024-20506
https://www.cve.org/CVERecord?id=CVE-2024-20506
[2] https://blog.clamav.net/2024/09/clamav-141-132-107-and-010312-security.html

Regards,
Salvatore

Bug#1080200: closing 1080200

[Salvatore Bonaccorso]

Hi Mike,

On Sat, Aug 31, 2024 at 02:16:06PM +0100, Mike Ricketts wrote:
> On 31/08/2024 13:44, Salvatore Bonaccorso wrote:
> > close 1080200
> > thanks
> > 
> > bullseye-backports is discontinued, situation would resolve once the signed
> > packages are around. For bullseye-backports the latest available was:
> > 
> > linux-signed-amd64 | 6.1.90+1~bpo11+1   | bullseye-backports | source
> 
> Whilst bullseye-backports is discontinued, this problem means it is
> impossible to get the system into a clean state in order to upgrade to
> bullseye (which is what I was trying to do when I discovered this).
> 
> linux-signed-amd64 version 6.1.90-1~bpo11+1 seems to be old half available
> in bullseye-backports - the linux-image package is there, but the
> linux-headers is not.
> 
> Will the linux-headers-amd64 package in bullseye-backports ever be fixed, or
> do we have to upgrade to bullseye from a system with broken packages and
> just hope it all goes ok?

The package would not be fixed anymore, see

https://lists.debian.org/debian-backports/2024/08/msg8.html

this was the missing bit needed to get the signed packages in.

That said you have several options:

- Update the system to bookworm (preferred)
- if you have to stick with bullseye, which is now maintained by the
  Debian LTS team, a linux-6.1 source package will be provided which
  continues to provide 6.1.y series for bullseye (via
  bullseye-security, but not anymore through bullseye-backports).

Ben might give some details when such packages are to be expected.

Does this help?

Regards,
Salvatore

Bug#1080218: libvirt: CVE-2024-8235

[Salvatore Bonaccorso]

Source: libvirt
Version: 10.6.0-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libvirt.

CVE-2024-8235[0]:
| A flaw was found in libvirt. A refactor of the code fetching the
| list of interfaces for multiple APIs introduced a corner case on
| platforms where allocating 0 bytes of memory results in a NULL
| pointer. This corner case would lead to a NULL-pointer dereference
| and subsequent crash of virtinterfaced. This issue could allow
| clients connecting to the read-only socket to crash the
| virtinterfaced daemon.

A note on the severity: Technically I think 'important' would have
been more appropriate. Still ideally this needs to be fixed for
trixie, so raise the level such that it appears on the radar before
the trixie freeze. I expect anyway that pkg-libvirt-maintainers are
reactive enough on bugfixes, so if you feel strong about it please do
downgrade the severity.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-8235
https://www.cve.org/CVERecord?id=CVE-2024-8235
[1] 
https://gitlab.com/libvirt/libvirt/-/commit/8dfb12cb77996519901b8d52c754ab564ebd10e8

Regards,
Salvatore

Bug#1080200: closing 1080200

[Salvatore Bonaccorso]

close 1080200 
thanks

bullseye-backports is discontinued, situation would resolve once the signed
packages are around. For bullseye-backports the latest available was:

linux-signed-amd64 | 6.1.90+1~bpo11+1   | bullseye-backports | source

Bug#1054814: (no subject)

[Salvatore Bonaccorso]

Hi,

On Sat, Aug 24, 2024 at 09:08:14PM +0200, Aleksandr Mikhalitsyn wrote:
> On Sat, Aug 24, 2024 at 8:48 PM Salvatore Bonaccorso  
> wrote:
> >
> > Hi,
> 
> Hi Salvatore,
> 
> >
> > On Sat, Aug 24, 2024 at 08:28:20PM +0200, Alexander Mikhalitsyn wrote:
> > > Dear friends,
> > >
> > > I'm trying to fix CRIU package in Ubuntu Noble:
> > > https://bugs.launchpad.net/ubuntu/+source/criu/+bug/2066148
> > >
> > > We had a discussion with my colleague Simon Déziel about my
> > > debdiff [1] for CRIU package in Ubuntu and he pointed me out that
> > > there is a bug on Debian bugtracker about these build issues.
> > >
> > > Of course, I would like to help to fix all problems with CRIU
> > > package in Debian too. (And hopefully, these changes will
> > > be autoinherited by Ubuntu.)
> > >
> > > As far as I understand, I need to prepare a PR that includes
> > > patches from debdiff for master branch (based on CRIU 3.19).
> > > What I can't understand is why debian/sid still uses 3.17 release?
> > > Do I need to fix 3.17 branch too?
> > >
> > > JFYI. We are preparing a new CRIU release 4.0:
> > > https://github.com/checkpoint-restore/criu/pull/2467
> >
> > The main issue right now I have with criu and blocking 3.19 is the
> > build part for the python code, I'm unable to make it ocrrectly build
> > with pyproject.
> 
> Is this locally reproducible?
> Can I just take the debian/sid container, pull the master branch from
> https://salsa.debian.org/debian/criu and do debuild to see the problem?

Yes, that plus the current WIP patch to try to make the python code
build with pybuild integration.

Once I have this resoved I'm really more than happy to move on with
the version (and then timely follow with 4.0 once thats out).

Regards,
Salvatore

Bug#1054814: (no subject)

[Salvatore Bonaccorso]

Hi,

On Sat, Aug 24, 2024 at 08:28:20PM +0200, Alexander Mikhalitsyn wrote:
> Dear friends,
> 
> I'm trying to fix CRIU package in Ubuntu Noble:
> https://bugs.launchpad.net/ubuntu/+source/criu/+bug/2066148
> 
> We had a discussion with my colleague Simon Déziel about my
> debdiff [1] for CRIU package in Ubuntu and he pointed me out that
> there is a bug on Debian bugtracker about these build issues.
> 
> Of course, I would like to help to fix all problems with CRIU
> package in Debian too. (And hopefully, these changes will
> be autoinherited by Ubuntu.)
> 
> As far as I understand, I need to prepare a PR that includes
> patches from debdiff for master branch (based on CRIU 3.19).
> What I can't understand is why debian/sid still uses 3.17 release?
> Do I need to fix 3.17 branch too?
> 
> JFYI. We are preparing a new CRIU release 4.0:
> https://github.com/checkpoint-restore/criu/pull/2467

The main issue right now I have with criu and blocking 3.19 is the
build part for the python code, I'm unable to make it ocrrectly build
with pyproject.

My current workdir on top of the packaging in the salsa repository
looks like:

diff --git a/debian/control b/debian/control
index 20feb59c9a9c..bde1d5cfbe17 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Build-Depends:
  pkg-config,
  protobuf-c-compiler,
  protobuf-compiler,
+ pybuild-plugin-pyproject,
  python3-all,
  xmlto
 Standards-Version: 4.6.2
diff --git a/debian/rules b/debian/rules
index 59e3370137e6..bb1480f2106f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,12 +1,16 @@
 #!/usr/bin/make -f

 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export PYBUILD_SYSTEM=pyproject
+export PYBUILD_NAME=pycriu
+export PYBUILD_DIR=lib
+export PYBUILD_VERBOSE=1

 PACKAGE = $(firstword $(shell dh_listpackages))
 TMP = $(CURDIR)/debian/$(PACKAGE)

 %:
-   dh ${@} --with python3
+   dh ${@} --with python3 --buildsystem=pybuild

 override_dh_auto_install:
dh_auto_install -- DESTDIR="$(CURDIR)/debian/criu" PREFIX="/usr" 
LIBEXECDIR="/usr/lib" PYTHON="python3"

I would very much appreciate help with that so I can move forward with
uploading 3.19.

I will have a look at what is done in Ubuntu.

Regards,
Salvatore

Bug#1079487: olm: CVE-2024-45191 CVE-2024-45192 CVE-2024-45193

[Salvatore Bonaccorso]

Source: olm
Version: 3.2.16+dfsg-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for olm.

CVE-2024-45191[0]:
| An issue was discovered in Matrix libolm (aka Olm) through 3.2.16.
| The AES implementation is vulnerable to cache-timing attacks due to
| use of S-boxes. This is related to software that uses a lookup table
| for the SubWord step. NOTE: This vulnerability only affects products
| that are no longer supported by the maintainer.


CVE-2024-45192[1]:
| An issue was discovered in Matrix libolm (aka Olm) through 3.2.16.
| Cache-timing attacks can occur due to use of base64 when decoding
| group session keys. NOTE: This vulnerability only affects products
| that are no longer supported by the maintainer.


CVE-2024-45193[2]:
| An issue was discovered in Matrix libolm (aka Olm) through 3.2.16.
| There is Ed25519 signature malleability due to lack of validation
| criteria (does not ensure that S < n). NOTE: This vulnerability only
| affects products that are no longer supported by the maintainer.

Note, that olm as beeing deprecated won't fix these issue, instead the
upstrem project commited:

https://gitlab.matrix.org/matrix-org/olm/-/commit/6d4b5b07887821a95b144091c8497d09d377f985

Should src:olm be removed from Debian (unstable)? There will be broken
reverse dependencies. Are they actually still usable for having in
Debian as well?

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-2024-45191
https://www.cve.org/CVERecord?id=CVE-2024-45191
[1] https://security-tracker.debian.org/tracker/CVE-2024-45192
https://www.cve.org/CVERecord?id=CVE-2024-45192
[2] https://security-tracker.debian.org/tracker/CVE-2024-45193
https://www.cve.org/CVERecord?id=CVE-2024-45193

Regards,
Salvatore

Bug#1078880: [Pkg-javascript-devel] Bug#1078880: gettext.js: CVE-2024-43370

[Salvatore Bonaccorso]

Hi Xavier,

On Tue, Aug 20, 2024 at 05:33:49PM +0400, Yadd wrote:
> On 8/20/24 17:30, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Tue, Aug 20, 2024 at 05:20:38PM +0400, Yadd wrote:
> > > On 8/20/24 16:34, Moritz M??hlenhoff wrote:
> > > > Hi Yadd,
> > > > 
> > > > > here is a simple patch for this issue
> > > > 
> > > > The debdiff looks fine, but I don't believe this needs a
> > > > DSA, can you please submit this for the next point update
> > > > instead?
> > > 
> > > Agree, but the bug was tagged as "grave" ;-)
> > 
> > The severity and the no-dsa/dsa decision can be orthogonal in the
> > following sense: Assume an issue is not severe enought to have an
> > immediate DSA, but a point release is approaching, still the issue
> > should be made sure to be fixed in the upper suite (considering it
> > release critical) so we would not start latest trixie with the open
> > issue.
> > 
> > Having it at RC level ensures this, gives enough grace time (there
> > won't be an imminent removal anyway) and raises the hint-flag.
> > 
> > I choose such in particular when I see there is the same version
> > across several releases, and a new upstream version exists to really
> > make sure we avoid having the issue in the upper suite.
> > 
> > Does this make sense? Or have you issues with the assessment as
> > 'grave' in this case?
> 
> No problem, I just filed issues for Bookworm and Bullseye

Thank you!

Regards,
Salvatore

Bug#1078880: [Pkg-javascript-devel] Bug#1078880: gettext.js: CVE-2024-43370

[Salvatore Bonaccorso]

Hi,

On Tue, Aug 20, 2024 at 05:20:38PM +0400, Yadd wrote:
> On 8/20/24 16:34, Moritz M??hlenhoff wrote:
> > Hi Yadd,
> > 
> > > here is a simple patch for this issue
> > 
> > The debdiff looks fine, but I don't believe this needs a
> > DSA, can you please submit this for the next point update
> > instead?
> 
> Agree, but the bug was tagged as "grave" ;-)

The severity and the no-dsa/dsa decision can be orthogonal in the
following sense: Assume an issue is not severe enought to have an
immediate DSA, but a point release is approaching, still the issue
should be made sure to be fixed in the upper suite (considering it
release critical) so we would not start latest trixie with the open
issue.

Having it at RC level ensures this, gives enough grace time (there
won't be an imminent removal anyway) and raises the hint-flag. 

I choose such in particular when I see there is the same version
across several releases, and a new upstream version exists to really
make sure we avoid having the issue in the upper suite.

Does this make sense? Or have you issues with the assessment as
'grave' in this case?

Regards,
Salvatore

Bug#1078876: closing 1078876

[Salvatore Bonaccorso]

close 1078876 1:2.3.21.1+dfsg1-1
thanks

Bug#1078970: fence-agents: CVE-2024-5651

[Salvatore Bonaccorso]

Source: fence-agents
Version: 4.15.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for fence-agents.

CVE-2024-5651[0]:
| A flaw was found in fence agents that rely on SSH/Telnet. This
| vulnerability can allow a Remote Code Execution (RCE) primitive by
| supplying an arbitrary command to execute in the --ssh-
| path/--telnet-path arguments. A low-privilege user, for example, a
| user with developer access, can create a specially crafted
| FenceAgentsRemediation for a fence agent supporting  --ssh-
| path/--telnet-path arguments to execute arbitrary commands on the
| operator's pod. This RCE leads to a privilege escalation, first as
| the service account running the operator, then to another service
| account with cluster-admin privileges.

Unfortunately, at time of writing this bugreport, the only reference I
have found for this CVE is the one linked in the CVE entry is [1].

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5651
https://www.cve.org/CVERecord?id=CVE-2024-5651
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2290540

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1078880: gettext.js: CVE-2024-43370

[Salvatore Bonaccorso]

Source: gettext.js
Version: 0.7.0-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gettext.js.

CVE-2024-43370[0]:
| gettext.js is a GNU gettext port for node and the browser. There is
| a cross-site scripting (XSS) injection if `.po` dictionary
| definition files are corrupted. This vulnerability has been patched
| in version 2.0.3. As a workaround, control the origin of the
| definition catalog to prevent the use of this flaw in the definition
| of plural forms.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-43370
https://www.cve.org/CVERecord?id=CVE-2024-43370
[1] 
https://github.com/guillaumepotier/gettext.js/security/advisories/GHSA-vwhg-jwr4-vxgg
[2] 
https://github.com/guillaumepotier/gettext.js/commit/6e52e0f8fa7d7c8b358e78b613d47ea332b8a56c

Regards,
Salvatore

Bug#1078829: linux-image-amd64: 6.10.3-1 fails to install with Nvidia DKMS build error

[Salvatore Bonaccorso]

Hi Alex,

On Fri, Aug 16, 2024 at 06:39:59PM -0300, Alex Henry wrote:
> Package: linux-image-amd64
> Version: 6.10.3-1
> Severity: important
> X-Debbugs-Cc: tuk...@gmail.com
> 
> Hello! I ran into some trouble while casually trying to update `linux-image-
> amd64`  and `linux-headers-amd64` during a routine system update.
> 
> My current image is `linux-image-6.9.7` (6.9.7-1). There are also some older
> images and headers marked as "auto" on Aptitude.
> 
> My installed `nvidia-driver` package is version 535.183.01-1. I have tripled-
> checked all installed Nvidia packages are fully up-ta-date in Debian-testing.
> 
> I have also updated all devel- and libdevel-category packages to make sure 
> this
> isn't an issue related to GCC, make...
> 
> Everything is working normally other than the failure to upgrade `linux-image-
> amd64`.
> 
> Logs:
> 
> - Aptitude output:
> https://gist.github.com/tukkek/863f4da63d925a50d3c7b49c33a4859f
> - `/var/lib/dkms/nvidia-current/535.183.01/build/make.log`:
> https://gist.github.com/tukkek/d91b07ad7792735381571f387aed13cd
> - Installed packages:
> https://gist.github.com/tukkek/2aa1b4407f9bcf7aa17053bcf43a2d4f
> 
> The only error I could find was "implicit declaration of function 
> ‘follow_pfn’"
> in the DKMS log's line 1371:
> https://gist.github.com/tukkek/d91b07ad7792735381571f387aed13cd#file-make-
> log-L1371
> 
> I'm not very familiar with kernel stuff and might have easily missed something
> so I'll let you geniuses take a better look. Let me know if I can provide any
> further information or help.
> 
> Big thanks to all involved in helping maintain the best libre operating system
> there is! Cheers!

See #1077841, which is the issue for src:nvidia-graphics-drivers. It
is fixed in 535.183.06-1 in unstable.

Regards,
Salvatore

Bug#1078742: intel-microcode: CVE-2024-25939 CVE-2024-24980 CVE-2024-24853 CVE-2023-49141 CVE-2023-42667

[Salvatore Bonaccorso]

Source: intel-microcode
Version: 3.20240531.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20240514.1~deb12u1
Control: found -1 3.20240514.1~deb11u1

Hi,

The following vulnerabilities were published for intel-microcode.

CVE-2024-25939[0]:
| Mirrored regions with different values in 3rd Generation Intel(R)
| Xeon(R) Scalable Processors may allow a privileged user to
| potentially enable denial of service via local access.


CVE-2024-24980[1]:
| Protection mechanism failure in some 3rd, 4th, and 5th Generation
| Intel(R) Xeon(R) Processors may allow a privileged user to
| potentially enable escalation of privilege via local access.


CVE-2024-24853[2]:
| Incorrect behavior order in transition between executive monitor and
| SMI transfer monitor (STM) in some Intel(R) Processor may allow a
| privileged user to potentially enable escalation of privilege via
| local access.


CVE-2023-49141[3]:
| Improper isolation in some Intel(R) Processors stream cache
| mechanism may allow an authenticated user to potentially enable
| escalation of privilege via local access.


CVE-2023-42667[4]:
| Improper isolation in the Intel(R) Core(TM) Ultra Processor stream
| cache mechanism may allow an authenticated user to potentially
| enable escalation of privilege via local access.


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-2024-25939
https://www.cve.org/CVERecord?id=CVE-2024-25939
[1] https://security-tracker.debian.org/tracker/CVE-2024-24980
https://www.cve.org/CVERecord?id=CVE-2024-24980
[2] https://security-tracker.debian.org/tracker/CVE-2024-24853
https://www.cve.org/CVERecord?id=CVE-2024-24853
[3] https://security-tracker.debian.org/tracker/CVE-2023-49141
https://www.cve.org/CVERecord?id=CVE-2023-49141
[4] https://security-tracker.debian.org/tracker/CVE-2023-42667
https://www.cve.org/CVERecord?id=CVE-2023-42667
[5] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20240813

Regards,
Salvatore

Bug#1076372: Re.: linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Stefan,

On Sat, Jul 27, 2024 at 02:27:15AM +0200, Stefan wrote:
> Hi Salvatore,
> 
> Am 26.07.24 um 23:09 schrieb Salvatore Bonaccorso:
> > Now that you were able to pinpoint two versions which are very close
> > together, would you be able to bisect the changes between 6.3.5 and
> > 6.3.7 to find the breaking commit upstream in that 6.3.y series?
> 
> not without spending more time I can effort ATM and without finding a
> better test procedure (currently 1-2h per run).
> 
> I'm not convinced that it is an ext4 bug. The corruption may also occur
> when the data is written to the nvm. The hardware (chipset-less AM5
> mainboard) is quite new, the only vendor (Asrock) probably does not care
> about Linux and maybe AMD did not tested is carefully enough. Thus,
> there a quite a lot of changes from 6.3.5 -> 6.3.7 that could cause the bug.
> 
> I'll try to find out more next week (other ways to reproduce the error,
> other hardware, ...), especially whether it is a  more general issue or
> hardware specific.

Were you able to get some more information or find other ways to
reproduce the error?

Is there actually a testcase other can run, or is this something
proprietary?

Regards,
Salvatore

Bug#1078574: asterisk: CVE-2024-42365

[Salvatore Bonaccorso]

Source: asterisk
Version: 1:20.8.1~dfsg+~cs6.14.40431414-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for asterisk.

CVE-2024-42365[0]:
| Asterisk is an open source private branch exchange (PBX) and
| telephony toolkit. Prior to asterisk versions 18.24.2, 20.9.2, and
| 21.4.2 and certified-asterisk versions 18.9-cert11 and 20.7-cert2,
| an AMI user with `write=originate` may change all configuration
| files in the `/etc/asterisk/` directory. This occurs because they
| are able to curl remote files and write them to disk, but are also
| able to append to existing files using the `FILE` function inside
| the `SET` application. This issue may result in privilege
| escalation, remote code execution and/or blind server-side request
| forgery with arbitrary protocol. Asterisk versions 18.24.2, 20.9.2,
| and 21.4.2 and certified-asterisk versions 18.9-cert11 and
| 20.7-cert2 contain a fix for this issue.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-42365
https://www.cve.org/CVERecord?id=CVE-2024-42365
[1] https://github.com/asterisk/asterisk/security/advisories/GHSA-c4cg-9275-6w44

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1074534: [Debian-med-packaging] Bug#1074534: dcm2niix: CVE-2024-27629

[Salvatore Bonaccorso]

Hi Étienne,

On Wed, Aug 07, 2024 at 10:54:25PM +0200, Étienne Mollier wrote:
> Control: found -1 1.0.20220720-1
> Control: notfound -1 1.0.20201102-1
> Control: tags -1 + bookworm
> 
> Greetings,
> 
> I tried to stress the CVE-2024-27629 affecting dcm2niix:
> | An issue in dc2niix before v.1.0.20240202 allows a local attacker to
> | execute arbitrary code via the generated file name is not properly
> | escaped and injected into a system call when certain types of
> | compression are used.
> 
> I think that I managed to trip the vulnerability on bookworm.
> But it seems that on bullseye, the file name embedded in the
> dicom file does not trip a shell command execution.  Unless I
> missed something, it seems that the problem did not exist à that
> time.
> 
> I'm considering preparing a bookworm proposed update with the
> patch for the next point release.  I'm less sure about touching
> bullseye for this one: the patch mangles file name upon
> conversion, and there is no real benefit if the problem indeed
> does not appear on that old operating system level.
> 
> Have a nice day,  :)

Thanks for your work! And thanks for preparing the bookworm-pu update
if you find time for it.

About bullseye, yes this might be, it might be dass the issue is
covered. If we are not 100% sure the vulnerable code os not there,
then rather err on the safe side and on tracker side do not mark it as
not-affected. But I agree then, that you leave the bullseye update out
for now. Maybe even leaning to mark it  in the
security-tracker for bullseye.

Regards,
Salvatore

Bug#1078030: lpfc: lost all san paths

[Salvatore Bonaccorso]

Control: severity -1 important
Control: tags -1 + moreinfo

Hi

You seem to run an old version 6.1.76-1, so please upgrade to the most
recent kernel provided in Debian bookworm (6.1.99-1).

On Tue, Aug 06, 2024 at 09:36:10AM +0200, Daniel Ufer wrote:
> Package: src:linux
> Version: 6.1.76-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation? -> normal usage, system is a postgresql 
> database host
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? -> reboot of the system fixed the problem
>* What was the outcome of this action? 
>* What outcome did you expect instead?

As we have only very little information here: Can you consistently
reproduce the issue under the specific workload with the current
6.1.99-1 in bookworm?

Regards,
Salvatore

Bug#1077767: mysql-connector-python: CVE-2024-21090 CVE-2024-21170

[Salvatore Bonaccorso]

Source: mysql-connector-python
Version: 8.0.15-4
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for mysql-connector-python.

CVE-2024-21090[0]:
| Vulnerability in the MySQL Connectors product of Oracle MySQL
| (component: Connector/Python).  Supported versions that are affected
| are 8.3.0 and prior. Easily exploitable vulnerability allows
| unauthenticated attacker with network access via multiple protocols
| to compromise MySQL Connectors.  Successful attacks of this
| vulnerability can result in unauthorized ability to cause a hang or
| frequently repeatable crash (complete DOS) of MySQL Connectors. CVSS
| 3.1 Base Score 7.5 (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).


CVE-2024-21170[1]:
| Vulnerability in the MySQL Connectors product of Oracle MySQL
| (component: Connector/Python).  Supported versions that are affected
| are 8.4.0 and prior. Easily exploitable vulnerability allows low
| privileged attacker with network access via multiple protocols to
| compromise MySQL Connectors.  Successful attacks of this
| vulnerability can result in  unauthorized update, insert or delete
| access to some of MySQL Connectors accessible data as well as
| unauthorized read access to a subset of MySQL Connectors accessible
| data and unauthorized ability to cause a partial denial of service
| (partial DOS) of MySQL Connectors. CVSS 3.1 Base Score 6.3
| (Confidentiality, Integrity and Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L).


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-2024-21090
https://www.cve.org/CVERecord?id=CVE-2024-21090
[1] https://security-tracker.debian.org/tracker/CVE-2024-21170
https://www.cve.org/CVERecord?id=CVE-2024-21170

Regards,
Salvatore

Bug#1077751: dnsjava: CVE-2023-50868

[Salvatore Bonaccorso]

Source: dnsjava
Version: 2.1.8-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for dnsjava.

CVE-2023-50868[0]:
| The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155
| when RFC 9276 guidance is skipped) allows remote attackers to cause
| a denial of service (CPU consumption for SHA-1 computations) via
| DNSSEC responses in a random subdomain attack, aka the "NSEC3"
| issue. The RFC 5155 specification implies that an algorithm must
| perform thousands of iterations of a hash function in certain
| situations.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-50868
https://www.cve.org/CVERecord?id=CVE-2023-50868
[1] https://github.com/advisories/GHSA-mmwx-rj87-vfgr
[2] 
https://github.com/dnsjava/dnsjava/commit/711af79be3214f52daa5c846b95766dc0a075116
 (v3.6.0)

Regards,
Salvatore

Bug#1077750: dnsjava: CVE-2023-50387

[Salvatore Bonaccorso]

Source: dnsjava
Version: 2.1.8-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for dnsjava.

CVE-2023-50387[0]:
| Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035,
| 6840, and related RFCs) allow remote attackers to cause a denial of
| service (CPU consumption) via one or more DNSSEC responses, aka the
| "KeyTrap" issue. One of the concerns is that, when there is a zone
| with many DNSKEY and RRSIG records, the protocol specification
| implies that an algorithm must evaluate all combinations of DNSKEY
| and RRSIG records.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-50387
https://www.cve.org/CVERecord?id=CVE-2023-50387
[1] https://github.com/advisories/GHSA-crjg-w57m-rqqf
[2] 
https://github.com/dnsjava/dnsjava/commit/07ac36a11578cc1bce0cd8ddf2fe568f062aee78
 (v3.6.0)
[3] 
https://github.com/dnsjava/dnsjava/commit/3ddc45ce8cdb5c2274e10b7401416f497694e1cf
 (v3.6.0)

Regards,
Salvatore

Bug#1068782: Bug#1071322: News on those issues?

[Salvatore Bonaccorso]

Hi Jeremy,

On Sun, Jun 30, 2024 at 02:47:41PM +0200, Salvatore Bonaccorso wrote:
> Hi Jeremy,
> 
> On Mon, Jun 17, 2024 at 04:31:04PM -0400, Jeremy T. Bouse wrote:
> > Upstream had been MIA for years; its last release was in 2010. It appears
> > he has finally returned, but I haven't had time to deal with the new
> > version that was released two weeks ago.
> 
> Thanks for the answer. 
> 
> Question: will you find time to deal with those issues, before 17th of
> upciming month? Because then libesmtp and reverse dependencies will be
> removed otherwise from trixie.

FWIW, libesmtp and its reverse dependencies are now removed from
testing, so I'm pretty much interested seeing it in trixie. 

Upstream has not responded to the Ubuntu proposed patches in
https://github.com/libesmtp/libESMTP/issues/21 .

Can you try to approach upstream to see if upstream can deal with the
issue in their preferred way and we can cherry-pick the fixes as
needed?

Regards,
Salvatore

Bug#1077368: dnsjava: CVE-2024-25638

[Salvatore Bonaccorso]

Source: dnsjava
Version: 2.1.8-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for dnsjava.

CVE-2024-25638[0]:
| dnsjava is an implementation of DNS in Java. Records in DNS replies
| are not checked for their relevance to the query, allowing an
| attacker to respond with RRs from different zones. This
| vulnerability is fixed in 3.6.0.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-25638
https://www.cve.org/CVERecord?id=CVE-2024-25638
[1] https://github.com/dnsjava/dnsjava/security/advisories/GHSA-cfxw-4h78-h7fw
[2] 
https://github.com/dnsjava/dnsjava/commit/2073a0cdea2c560465f7ac0cc56f202e6fc39705

Regards,
Salvatore

Bug#1077281: DSA 5734-1 Regression: Segfaulting when including Samba-Configuration

[Salvatore Bonaccorso]

Hi,

On Sun, Jul 28, 2024 at 11:53:34AM +0200, Jan Lühr wrote:
> Hi,
> 
> 
> > Am 27.07.2024 um 23:19 schrieb Salvatore Bonaccorso :
> > 
> > On Sat, Jul 27, 2024 at 10:58:53PM +0200, Jan Lühr wrote:
> > 
> > See #1074378. Ondrej has prepared a followup update fixing the
> > regression, and an update should go out shortly.
> 
> thanks for the hint. I overlooked this bug when checking for duplicates.

No worries at all. The main focus was on pointing out the curren state
and the pending subsequent release with the regression fix.

Regards,
Salvatore

Bug#1077299: git: Not migrating to testing for long time due to autopkgtest results

[Salvatore Bonaccorso]

Source: git
Version: 1:2.45.2-1
Severity: serious
Justification: missing testing migration, autopkgtest regressions
X-Debbugs-Cc: car...@debian.org

Hi

This is to document the current missing testing migration. src:git
does not currently migrate to testing:

https://qa.debian.org/excuses.php?package=git

Testing: Excuse for git

  • Migration status for git (1:2.43.0-1 to 1:2.45.2-1): BLOCKED: Rejected/
violates migration policy/introduces a regression
  • Issues preventing migration:
  □ autopkgtest for ikiwiki-hosting/0.20220716-2: amd64: Regression or new
test ♻ (reference ♻), arm64: Regression or new test ♻ (reference ♻),
armel: Regression or new test ♻ (reference ♻), armhf: Regression or new
test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻),
ppc64el: Regression or new test ♻ (reference ♻), s390x: Regression or
new test ♻ (reference ♻)
  • Additional info:
  □ Updating git will fix bugs in testing: #1071160, #1074064
  □ Piuparts tested OK - https://piuparts.debian.org/sid/source/g/git.html
  □ Reproducible on amd64 - info ♻
  □ Reproducible on arm64 - info ♻
  □ Reproducible on armhf - info ♻
  □ Reproducible on i386 - info ♻
  □ 41 days old (needed 5 days)

Regards,
Salvatore

Bug#1077281: DSA 5734-1 Regression: Segfaulting when including Samba-Configuration

[Salvatore Bonaccorso]

Hi Jan,

On Sat, Jul 27, 2024 at 10:58:53PM +0200, Jan Lühr wrote:
> Package: bind9
> Version: 9.18.28-1~deb12u1
> 
> Hi,
> 
> [DSA 5734-1] (i.e. 9.18.28-1~deb12u1) caused a regression on my system Debian 
> 12 / amd64
> 
> Option include "/var/lib/samba/bind-dns/named.conf“;  - to have samba 
> resolving certain domains - 
> results in (syslog)
> 
> 2024-07-27T22:46:01.062152+02:00 colonia named[2541]: sizing zone task pool 
> based on 2 zones
> 2024-07-27T22:46:01.062312+02:00 colonia named[2541]: Loading 'AD DNS Zone' 
> using driver dlopen
> 2024-07-27T22:46:01.097363+02:00 colonia named[2541]: free(): invalid pointer
> 2024-07-27T22:46:01.140829+02:00 colonia systemd[1]: named.service: Main 
> process exited, code=dumped, status=6/ABRT
> 2024-07-27T22:46:01.140870+02:00 colonia systemd[1]: named.service: Failed 
> with result 'core-dump'.
> 2024-07-27T22:46:01.140905+02:00 colonia systemd[1]: Failed to start 
> named.service - BIND Domain Name Server.
> 2024-07-27T22:46:01.286204+02:00 colonia systemd[1]: named.service: Scheduled 
> restart job, restart counter is at 5.
> 2024-07-27T22:46:01.286255+02:00 colonia systemd[1]: Stopped named.service - 
> BIND Domain Name Server.
> 2024-07-27T22:46:01.286282+02:00 colonia systemd[1]: named.service: Start 
> request repeated too quickly.
> 2024-07-27T22:46:01.286302+02:00 colonia systemd[1]: named.service: Failed 
> with result 'core-dump'.
> 2024-07-27T22:46:01.286321+02:00 colonia systemd[1]: Failed to start 
> named.service - BIND Domain Name Server.
> 
> Rolling back to 9.18.24-1 serves as a workaround (i.e. the problem disappears)

See #1074378. Ondrej has prepared a followup update fixing the
regression, and an update should go out shortly.

Regards,
Salvatore

Bug#1076372: Re.: linux-image-6.5.0-0.deb12.4-amd64: ext4 file corruption with newer kernels

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Stefan,

On Fri, Jul 26, 2024 at 10:49:00AM +0200, Stefan wrote:
> The complete sentence is:
> 
> oldest non-working kernel is 6.3.7 (package linux-image-6.3.0-1-amd64),
> 6.3.5 (latest version of package package linux-image-6.3.0-0-amd64) works.

Now that you were able to pinpoint two versions which are very close
together, would you be able to bisect the changes between 6.3.5 and
6.3.7 to find the breaking commit upstream in that 6.3.y series?

Regards,
Salvatore

Bug#1077209: python-orjson: CVE-2024-27454

[Salvatore Bonaccorso]

Source: python-orjson
Version: 3.9.14-3
Severity: grave
Tags: security upstream
Forwarded: https://github.com/ijl/orjson/issues/458
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-orjson.

CVE-2024-27454[0]:
| orjson.loads in orjson before 3.9.15 does not limit recursion for
| deeply nested JSON documents.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27454
https://www.cve.org/CVERecord?id=CVE-2024-27454
[1] https://github.com/ijl/orjson/issues/458

Regards,
Salvatore

Bug#1077141: trafficserver: CVE-2023-38522 CVE-2024-35161 CVE-2024-35296

[Salvatore Bonaccorso]

Source: trafficserver
Version: 9.2.4+ds-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 9.2.4+ds-0+deb12u1
Control: found -1 8.1.10+ds-1~deb11u1

Hi,

The following vulnerabilities were published for trafficserver.

CVE-2023-38522[0]:
| Incomplete field name check allows request smuggling


CVE-2024-35161[1]:
| Incomplete check for chunked trailer section allows request smuggling


CVE-2024-35296[2]:
| Invalid Accept-Encoding can force forwarding requests


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-2023-38522
https://www.cve.org/CVERecord?id=CVE-2023-38522
[1] https://security-tracker.debian.org/tracker/CVE-2024-35161
https://www.cve.org/CVERecord?id=CVE-2024-35161
[2] https://security-tracker.debian.org/tracker/CVE-2024-35296
https://www.cve.org/CVERecord?id=CVE-2024-35296
[3] https://www.openwall.com/lists/oss-security/2024/07/25/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1074763: closing 1074763

[Salvatore Bonaccorso]

close 1074763 2:24.0.0-5
thanks

Fixed with the -5 upload, -4 did not enter the archive.

Bug#1074762: closing 1074762

[Salvatore Bonaccorso]

close 1074762 2:29.0.2-4
thanks

-3 was not uploaded, fixed in -4 including complete fix.

Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive

[Salvatore Bonaccorso]

Hi Paul,

On Sun, Jul 14, 2024 at 09:47:52AM +0200, Paul Gevers wrote:
> Hi,
> 
> On 09-07-2024 12:23 p.m., Paul Gevers wrote:
> > I'll see what I can do.
> 
> For the record: I have installed the unstable kernel on one of the workers
> (ci-worker-arm64-11 [1]). Let's see how it behaves.

Thanks a lot. Looking forward to hear how it goes.

Regards,
Salvatore

Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive

[Salvatore Bonaccorso]

Hi Paul,

On Thu, May 30, 2024 at 12:58:45PM +0100, Ben Hutchings wrote:
> On Thu, 2024-05-16 at 08:09 +0200, Paul Gevers wrote:
> > Hi Ben (and all the rest),
> > 
> > On 15-05-2024 9:56 p.m., Ben Hutchings wrote:
> > > Apologies for leaving this bug for so long.
> > 
> > NP, part of live I guess.
> > 
> > > Is this bug still occurring?
> > 
> > I don't know. The problem was severe enough for us to abandon the idea 
> > of running the backport kernels on our arm64 hosts, so we went back to 
> > the stable kernel there.
> > 
> > > I had a look for possibly related fixes,
> > > and found:
> > > 
> > > commit 22e111ed6c83dcde3037fc81176012721bc34c0b
> > 
> > [...]
> > 
> > > The fix went into
> > > 6.8-rc1 and was backported to 6.6.15, so Debian versions 6.6.15-1
> > > onward should have it.
> > 
> > > commit a8b0026847b8c43445c921ad2c85521c92eb175f
> > 
> > [...]
> > 
> > > which went into 6.8 but was *not* backported.
> > 
> > If you think it worth enough knowing if either is the case, I can 
> > install the backports kernel again on the arm64 hosts, but obviously 
> > that will be annoying for us. Please let me know if I should pursue this 
> > (I would be expecting a bit quicker turn around on this bug if you say 
> > yes now ;) ).
> 
> If you can test with the unstable kernel that would be great.  If you
> are limited to only stable and backports, then you should probably wait
> until 6.8 is in backports rather than testing the current 6.7 backport
> that has only one of the fixes.

In the last weekly kernel team meeting we discussed about some of the
open issues, and we wondered if you were able to test again with
either a unstable kernel, or if that's not possible with the current
versions available trough backports?

Unfortunately for the 6.8.y series though the package is not yet out
of backports-new. 

Regards,
Salvatore

Bug#1075729: znc: diff for NMU version 1.9.0-2.1

[Salvatore Bonaccorso]

Control: tags 1075729 + patch
Control: tags 1075729 + pending


Dear maintainer,

I've prepared an NMU for znc (versioned as 1.9.0-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru znc-1.9.0/debian/changelog znc-1.9.0/debian/changelog
--- znc-1.9.0/debian/changelog	2024-03-04 11:09:56.0 +0100
+++ znc-1.9.0/debian/changelog	2024-07-06 21:50:10.0 +0200
@@ -1,3 +1,10 @@
+znc (1.9.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix RCE vulnerability in modtcl (CVE-2024-39844) (Closes: #1075729)
+
+ -- Salvatore Bonaccorso   Sat, 06 Jul 2024 21:50:10 +0200
+
 znc (1.9.0-2) unstable; urgency=medium
 
   * Use argon2 for password hashing.
diff -Nru znc-1.9.0/debian/patches/Fix-RCE-vulnerability-in-modtcl.patch znc-1.9.0/debian/patches/Fix-RCE-vulnerability-in-modtcl.patch
--- znc-1.9.0/debian/patches/Fix-RCE-vulnerability-in-modtcl.patch	1970-01-01 01:00:00.0 +0100
+++ znc-1.9.0/debian/patches/Fix-RCE-vulnerability-in-modtcl.patch	2024-07-06 21:50:10.0 +0200
@@ -0,0 +1,62 @@
+From: Alexey Sokolov 
+Date: Mon, 1 Jul 2024 09:59:16 +0100
+Subject: Fix RCE vulnerability in modtcl
+Origin: https://github.com/znc/znc/commit/8cbf8d628174ddf23da680f3f117dc54da0eb06e
+Bug-Debian: https://bugs.debian.org/1075729
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-39844
+
+Remote attacker could execute arbitrary code embedded into the kick
+reason while kicking someone on a channel.
+
+To mitigate this for existing installations, simply unload the modtcl
+module for every user, if it's loaded.
+Note that only users with admin rights can load modtcl at all.
+
+While at it, also escape the channel name.
+
+Discovered by Johannes Kuhn (DasBrain)
+
+Patch by https://github.com/glguy
+
+CVE-2024-39844
+---
+ modules/modtcl.cpp | 9 ++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/modules/modtcl.cpp b/modules/modtcl.cpp
+index df7f92f4d504..365da2e735ca 100644
+--- a/modules/modtcl.cpp
 b/modules/modtcl.cpp
+@@ -248,8 +248,9 @@ class CModTcl : public CModule {
+ // chan specific
+ unsigned int nLength = vChans.size();
+ for (unsigned int n = 0; n < nLength; n++) {
++CString sChannel = TclEscape(CString(vChans[n]->GetName()));
+ sCommand = "Binds::ProcessNick {" + sOldNick + "} {" + sHost +
+-   "} - {" + vChans[n]->GetName() + "} {" + sNewNickTmp +
++   "} - {" + sChannel + "} {" + sNewNickTmp +
+"}";
+ int i = Tcl_Eval(interp, sCommand.c_str());
+ if (i != TCL_OK) {
+@@ -260,14 +261,16 @@ class CModTcl : public CModule {
+ 
+ void OnKick(const CNick& OpNick, const CString& sKickedNick, CChan& Channel,
+ const CString& sMessage) override {
++CString sMes = TclEscape(sMessage);
+ CString sOpNick = TclEscape(CString(OpNick.GetNick()));
+ CString sNick = TclEscape(sKickedNick);
+ CString sOpHost =
+ TclEscape(CString(OpNick.GetIdent() + "@" + OpNick.GetHost()));
++CString sChannel = TclEscape(Channel.GetName());
+ 
+ CString sCommand = "Binds::ProcessKick {" + sOpNick + "} {" + sOpHost +
+-   "} - {" + Channel.GetName() + "} {" + sNick + "} {" +
+-   sMessage + "}";
++   "} - {" + sChannel + "} {" + sNick + "} {" +
++   sMes + "}";
+ int i = Tcl_Eval(interp, sCommand.c_str());
+ if (i != TCL_OK) {
+ PutModule(Tcl_GetStringResult(interp));
+-- 
+2.45.2
+
diff -Nru znc-1.9.0/debian/patches/series znc-1.9.0/debian/patches/series
--- znc-1.9.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ znc-1.9.0/debian/patches/series	2024-07-06 21:50:10.0 +0200
@@ -0,0 +1 @@
+Fix-RCE-vulnerability-in-modtcl.patch

Bug#1075824: qemu: CVE-2024-4467

[Salvatore Bonaccorso]

Hi Michael,

[looping in team@s.d.o as we do not automatically are CCed on security
tagged bugs, so for conext of the other team members]

On Sat, Jul 06, 2024 at 09:27:45AM +0300, Michael Tokarev wrote:
> Control: found -1
> 06.07.2024 00:35, Salvatore Bonaccorso wrote:
> ..
> > > This is fixed by qemu uploaded earlier today.
> > > 
> > > Patches are already prepared for bookworm (for qemu 7.2.x series) and
> > > already verified upstream and passed the tests.
> > 
> > Yes thanks, had only the 1:8.2.5+ds-2 initially to check.
> 
> Sure, you didn't know I uploaded a fixed version already.

Well I still consider that a bit sloopy on my end, I usually check
various sources, one of which is as well if tracker did see a new
changes :). anyway, I think all sorted with respect to unstable :)

> > Updated the security-tracker accordingly now.
> 
> Now, I've some doubts about what to do here with other branches.
> 
> For bookworm we've two choices: to upload a quick fix to -security
> with just the two changes from upstream, or to wait for upstream
> 7.2.13 version which will be released in 10 days, and push that
> one with this and other fixes.  I prefer the second variant, but
> you definitely have your word here.

Yes right, and what is your take on the severity? I think the later
option is better to cover potential other fixes, e.g. I guess
CVE-2024-6505 will be adressed as well (though not checked that yet
closely).

OTOH there is the question if we need a DSA or if the rebase update
can be batched in the point release from august so having the update
further exposed via proposed-updates.

But in short I do not see an urgency that we cannot wait at least the
10 days.

> And since this bug is old (can't find when the json thing first
> appeared, but it looks like it predates buster).  I'll update the
> bug report at least.

Ack!

Thanks for your work on qemu (and other packages)

Regards,
Salvatore

Bug#1075824: closed by Michael Tokarev (Re: Bug#1075824: qemu: CVE-2024-4467)

[Salvatore Bonaccorso]

Hi,

On Fri, Jul 05, 2024 at 09:27:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:qemu package:
> 
> #1075824: qemu: CVE-2024-4467
> 
> It has been closed by Michael Tokarev .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Michael Tokarev 
>  by
> replying to this email.
> 
> 
> -- 
> 1075824: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075824
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> From: Michael Tokarev 
> User-Agent: Mozilla Thunderbird
> Date: Sat, 6 Jul 2024 00:23:36 +0300
> To: 1075824-d...@bugs.debian.org
> Subject: Re: Bug#1075824: qemu: CVE-2024-4467
> Message-ID: <85f6d51a-8c62-46ce-b38b-7ec5d4409...@tls.msk.ru>
> 
> Version: 1:9.0.1+ds-1
> 
> 05.07.2024 23:41, Salvatore Bonaccorso wrote:
> > Source: qemu
> > Version: 1:8.2.5+ds-2
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for qemu.
> > 
> > CVE-2024-4467[0]:
> > | A flaw was found in the QEMU disk image utility (qemu-img) 'info'
> > | command. A specially crafted image file containing a `json:{}` value
> > | describing block devices in QMP could cause the qemu-img process on
> > | the host to consume large amounts of memory or CPU time, leading to
> > | denial of service or read/write to an existing external file.
> 
> This is fixed by qemu uploaded earlier today.
> 
> Patches are already prepared for bookworm (for qemu 7.2.x series) and
> already verified upstream and passed the tests.

Yes thanks, had only the 1:8.2.5+ds-2 initially to check.

Updated the security-tracker accordingly now.

Regards,
Salvatore

Bug#1075824: qemu: CVE-2024-4467

[Salvatore Bonaccorso]

Source: qemu
Version: 1:8.2.5+ds-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2024-4467[0]:
| A flaw was found in the QEMU disk image utility (qemu-img) 'info'
| command. A specially crafted image file containing a `json:{}` value
| describing block devices in QMP could cause the qemu-img process on
| the host to consume large amounts of memory or CPU time, leading to
| denial of service or read/write to an existing external file.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-4467
https://www.cve.org/CVERecord?id=CVE-2024-4467
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2278875
[2] 
https://gitlab.com/qemu-project/qemu/-/commit/bd385a5298d7062668e804d73944d52aec9549f1

https://gitlab.com/qemu-project/qemu/-/commit/2eb42a728d27a43fdcad5f37d3f65706ce6deba5

https://gitlab.com/qemu-project/qemu/-/commit/7e1110664ecbc4826f3c978ccb06b6c1bce823e6

https://gitlab.com/qemu-project/qemu/-/commit/7ead946998610657d38d1a505d5f25300d4ca613

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1075785: exim4: CVE-2024-39929: Incorrect parsing of multiline rfc2231 header filename

[Salvatore Bonaccorso]

Source: exim4
Version: 4.97-8
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugs.exim.org/show_bug.cgi?id=3099
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for exim4.

CVE-2024-39929[0]:
| Exim through 4.97.1 misparses a multiline RFC 2231 header filename,
| and thus remote attackers can bypass a $mime_filename extension-
| blocking protection mechanism, and potentially deliver executable
| attachments to the mailboxes of end users.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-39929
https://www.cve.org/CVERecord?id=CVE-2024-39929
[1] https://bugs.exim.org/show_bug.cgi?id=3099#c4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1075729: znc: CVE-2024-39844

[Salvatore Bonaccorso]

Source: znc
Version: 1.9.0-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.8.2-2
Control: found -1 1.8.2-3.1
Control: fixed -1 1.8.2-2+deb11u1
Control: fixed -1 1.8.2-3.1+deb12u1

Hi,

The following vulnerability was published for znc.

CVE-2024-39844[0]:
| In ZNC before 1.9.1, remote code execution can occur in modtcl via a
| KICK.

The version with above fixed versions were uploaded to security-master
and will be released in the upcoming DSA for znc.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-39844
https://www.cve.org/CVERecord?id=CVE-2024-39844
[1] https://wiki.znc.in/ChangeLog/1.9.1
[2] https://github.com/znc/znc/commit/8cbf8d628174ddf23da680f3f117dc54da0eb06e

Regards,
Salvatore

Bug#1074534: dcm2niix: CVE-2024-27629

[Salvatore Bonaccorso]

Source: dcm2niix
Version: 1.0.20220720-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/rordenlab/dcm2niix/pull/789
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for dcm2niix.

CVE-2024-27629[0]:
| An issue in dc2niix before v.1.0.20240202 allows a local attacker to
| execute arbitrary code via the generated file name is not properly
| escaped and injected into a system call when certain types of
| compression are used.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27629
https://www.cve.org/CVERecord?id=CVE-2024-27629
[1] https://github.com/rordenlab/dcm2niix/pull/789

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068782: Bug#1071322: News on those issues?

[Salvatore Bonaccorso]

Hi Jeremy,

On Mon, Jun 17, 2024 at 04:31:04PM -0400, Jeremy T. Bouse wrote:
> Upstream had been MIA for years; its last release was in 2010. It appears
> he has finally returned, but I haven't had time to deal with the new
> version that was released two weeks ago.

Thanks for the answer. 

Question: will you find time to deal with those issues, before 17th of
upciming month? Because then libesmtp and reverse dependencies will be
removed otherwise from trixie.

Regards,
Salvatore

Bug#1074486: wordpress: CVE-2024-6307 CVE-2024-31111 CVE-2024-32111

[Salvatore Bonaccorso]

Source: wordpress
Version: 6.5.3+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for wordpress.

CVE-2024-6307[0]:
| WordPress Core is vulnerable to Stored Cross-Site Scripting via the
| HTML API in various versions prior to 6.5.5 due to insufficient
| input sanitization and output escaping on URLs. This makes it
| possible for authenticated attackers, with contributor-level access
| and above, to inject arbitrary web scripts in pages that will
| execute whenever a user accesses an injected page.


CVE-2024-3[1]:
| Improper Neutralization of Input During Web Page Generation (XSS or
| 'Cross-site Scripting') vulnerability in Automattic WordPress allows
| Stored XSS.This issue affects WordPress: from 6.5 through 6.5.4,
| from 6.4 through 6.4.4, from 6.3 through 6.3.4, from 6.2 through
| 6.2.5, from 6.1 through 6.1.6, from 6.0 through 6.0.8, from 5.9
| through 5.9.9.


CVE-2024-32111[2]:
| Improper Limitation of a Pathname to a Restricted Directory ('Path
| Traversal') vulnerability in Automattic WordPress allows Relative
| Path Traversal.This issue affects WordPress: from 6.5 through 6.5.4,
| from 6.4 through 6.4.4, from 6.3 through 6.3.4, from 6.2 through
| 6.2.5, from 6.1 through 6.1.6, from 6.0 through 6.0.8, from 5.9
| through 5.9.9, from 5.8 through 5.8.9, from 5.7 through 5.7.11, from
| 5.6 through 5.6.13, from 5.5 through 5.5.14, from 5.4 through
| 5.4.15, from 5.3 through 5.3.17, from 5.2 through 5.2.20, from 5.1
| through 5.1.18, from 5.0 through 5.0.21, from 4.9 through 4.9.25,
| from 4.8 through 4.8.24, from 4.7 through 4.7.28, from 4.6 through
| 4.6.28, from 4.5 through 4.5.31, from 4.4 through 4.4.32, from 4.3
| through 4.3.33, from 4.2 through 4.2.37, from 4.1 through 4.1.40.


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-2024-6307
https://www.cve.org/CVERecord?id=CVE-2024-6307
[1] https://security-tracker.debian.org/tracker/CVE-2024-3
https://www.cve.org/CVERecord?id=CVE-2024-3
[2] https://security-tracker.debian.org/tracker/CVE-2024-32111
https://www.cve.org/CVERecord?id=CVE-2024-32111
[3] https://wordpress.org/news/2024/06/wordpress-6-5-5/

Regards,
Salvatore

Bug#1074483: dcmtk: CVE-2024-27628

[Salvatore Bonaccorso]

Source: dcmtk
Version: 3.6.7-15
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://support.dcmtk.org/redmine/issues/1108
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.6.7-9~deb12u1

Hi,

The following vulnerability was published for dcmtk.

CVE-2024-27628[0]:
| Buffer Overflow vulnerability in DCMTK v.3.6.8 allows an attacker to
| execute arbitrary code via the EctEnhancedCT method component.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27628
https://www.cve.org/CVERecord?id=CVE-2024-27628
[1] https://support.dcmtk.org/redmine/issues/1108
[2] 
https://github.com/DCMTK/dcmtk/commit/ec52e99e1e33fc39810560421c0833b02da567b3

Regards,
Salvatore

Bug#1074351: rust-curve25519-dalek: RUSTSEC-2024-0344

[Salvatore Bonaccorso]

Hi Jonas,

On Thu, Jun 27, 2024 at 10:52:47PM +0200, Jonas Smedegaard wrote:
> Quoting Salvatore Bonaccorso (2024-06-27 08:03:39)
> > There is RUSTSEC-2024-0344 provided for rust-curve25519-dalek, can you
> > have a look for unstable?
> > 
> > https://rustsec.org/advisories/RUSTSEC-2024-0344.html
> > https://github.com/dalek-cryptography/curve25519-dalek/pull/659
> 
> Certainly - it is on its way now...

Thanks for dealing with it!

Regards,
Salvatore

Bug#1074351: rust-curve25519-dalek: RUSTSEC-2024-0344

[Salvatore Bonaccorso]

Source: rust-curve25519-dalek
Version: 4+20240603+dfsg-2
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/dalek-cryptography/curve25519-dalek/pull/659
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi

There is RUSTSEC-2024-0344 provided for rust-curve25519-dalek, can you
have a look for unstable?

https://rustsec.org/advisories/RUSTSEC-2024-0344.html
https://github.com/dalek-cryptography/curve25519-dalek/pull/659

Regards,
Salvatore

Bug#1074136: org-link-expand-abbrev: Do not evaluate arbitrary unsafe Elisp code

[Salvatore Bonaccorso]

Source: org-mode
Version: 9.6.28+dfsg-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:emacs 1:29.3+1-3

Hi

There is a new vulnerability in Emacs Org mode. Details:

https://www.openwall.com/lists/oss-security/2024/06/23/1

Upstream fix (in org-mode);

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f4cc61636947b5c2f0afc67174dd369fe3277aa8

Regards,
Salvatore

Bug#1072885: closing 1072885

[Salvatore Bonaccorso]

close 1072885 8.2.20-2
thanks

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Salvatore Bonaccorso]

Hi Jörn,

On Fri, Jun 21, 2024 at 04:21:36PM +0200, Jörn Heusipp wrote:
> 
> > Looks like it just missed 6.9.5. Hopefully it will be in 6.9.6 then.
> 
> The fix landed in upstream 6.9.6.

Thanks!

Regards,
Salvatore

Bug#1068782: News on those issues?

[Salvatore Bonaccorso]

Hi Jeremy,

Any news on #1068782 and #1071322?  There are a couple of reverse
dependencies as well scheduled for autoremoval if libesmtp is removed.

Regards,
Salvatore

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

Hi Jörn,

On Sun, Jun 16, 2024 at 03:50:57PM +0200, Jörn Heusipp wrote:
> 
> This is fixed in upstream 6.10:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.10-rc3&id=2a38e4ca302280fdcce370ba2bee79bac16c4587
> 
> and should also end up back-ported in 6.9.5:
>  https://lore.kernel.org/all/20240616133543.1590007-1-osm...@heusipp.de/

Thanks for the notification. So this will end in our next upload based
on at least 6.9.5.

Regards,
Salvatore

Bug#1073250: liboqs: CVE-2024-36405

[Salvatore Bonaccorso]

Source: liboqs
Version: 0.8.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for liboqs.

CVE-2024-36405[0]:
| liboqs is a C-language cryptographic library that provides
| implementations of post-quantum cryptography algorithms. A control-
| flow timing lean has been identified in the reference implementation
| of the Kyber key encapsulation mechanism when it is compiled with
| Clang 15-18 for `-Os`, `-O1`, and other compilation options. A
| proof-of-concept local attack on the reference implementation leaks
| the entire ML-KEM 512 secret key in ~10 minutes using end-to-end
| decapsulation timing measurements. The issue has been fixed in
| version 0.10.1. As a possible workaround, some compiler options may
| produce vectorized code that does not leak secret information,
| however relying on these compiler options as a workaround may not be
| reliable.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-36405
https://www.cve.org/CVERecord?id=CVE-2024-36405
[1] 
https://github.com/open-quantum-safe/liboqs/security/advisories/GHSA-f2v9-5498-2vpp

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1073249: booth: CVE-2024-3049

[Salvatore Bonaccorso]

Source: booth
Version: 1.1-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/ClusterLabs/booth/pull/142
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for booth.

CVE-2024-3049[0]:
| A flaw was found in Booth, a cluster ticket manager. If a specially-
| crafted hash is passed to gcry_md_get_algo_dlen(), it may allow an
| invalid HMAC to be accepted by the Booth server.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-3049
https://www.cve.org/CVERecord?id=CVE-2024-3049
[1] https://github.com/ClusterLabs/booth/pull/142

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1073126: composer: CVE-2024-35242: Multiple command injections via malicious git/hg branch names

[Salvatore Bonaccorso]

Source: composer
Version: 2.7.6-3
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for composer.

CVE-2024-35242[0]:
| Composer is a dependency manager for PHP. On the 2.x branch prior to
| versions 2.2.24 and 2.7.7, the `composer install` command running
| inside a git/hg repository which has specially crafted branch names
| can lead to command injection. This requires cloning untrusted
| repositories. Patches are available in version 2.2.24 for 2.2 LTS or
| 2.7.7 for mainline. As a workaround, avoid cloning potentially
| compromised repositories.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-35242
https://www.cve.org/CVERecord?id=CVE-2024-35242
[1] https://github.com/composer/composer/security/advisories/GHSA-v9qv-c7wm-wgmf

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1073125: composer: CVE-2024-35241: Command injection via malicious git branch name

[Salvatore Bonaccorso]

Source: composer
Version: 2.7.6-3
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for composer.

CVE-2024-35241[0]:
| Composer is a dependency manager for PHP. On the 2.x branch prior to
| versions 2.2.24 and 2.7.7, the `status`, `reinstall` and `remove`
| commands with packages installed from source via git containing
| specially crafted branch names in the repository can be used to
| execute code. Patches for this issue are available in version 2.2.24
| for 2.2 LTS or 2.7.7 for mainline. As a workaround, avoid installing
| dependencies via git by using `--prefer-dist` or the `preferred-
| install: dist` config setting.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-35241
https://www.cve.org/CVERecord?id=CVE-2024-35241
[1] https://github.com/composer/composer/security/advisories/GHSA-47f6-5gq3-vx9c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1072969: pytorch: CVE-2024-5480

[Salvatore Bonaccorso]

Source: pytorch
Version: 2.1.2+dfsg-4
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pytorch.

CVE-2024-5480[0]:
| A vulnerability in the PyTorch's torch.distributed.rpc framework,
| specifically in versions prior to 2.2.2, allows for remote code
| execution (RCE). The framework, which is used in distributed
| training scenarios, does not properly verify the functions being
| called during RPC (Remote Procedure Call) operations. This oversight
| permits attackers to execute arbitrary commands by leveraging built-
| in Python functions such as eval during multi-cpu RPC communication.
| The vulnerability arises from the lack of restriction on function
| calls when a worker node serializes and sends a PythonUDF (User
| Defined Function) to the master node, which then deserializes and
| executes the function without validation. This flaw can be exploited
| to compromise master nodes initiating distributed training,
| potentially leading to the theft of sensitive AI-related data.

Looking at the changes up to 2.2.2 upstream it is not clear to me
where it has been fixed. It might be possible that it's still unfixed
in that tagged version (i.e. do not trust CVE descriptions). Can you
double-check this?

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5480
https://www.cve.org/CVERecord?id=CVE-2024-5480
[1] https://huntr.com/bounties/39811836-c5b3-4999-831e-46fee8fcade3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1072885: php8.2: CVE-2024-4577 CVE-2024-5458

[Salvatore Bonaccorso]

Source: php8.2
Version: 8.2.18-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for php8.2.

CVE-2024-4577[0]:
| Bypass of CVE-2012-1823, Argument Injection in PHP-CGI


CVE-2024-5458[1]:
| In PHP versions 8.1.* before 8.1.29, 8.2.* before 8.2.20, 8.3.*
| before 8.3.8, due to a code logic error, filtering functions such as
| filter_var when validating URLs (FILTER_VALIDATE_URL) for certain
| types of URLs the function will result in invalid user information
| (username + password part of URLs) being treated as valid user
| information. This may lead to the downstream code accepting invalid
| URLs as valid and parsing them incorrectly.


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-2024-4577
https://www.cve.org/CVERecord?id=CVE-2024-4577
[1] https://security-tracker.debian.org/tracker/CVE-2024-5458
https://www.cve.org/CVERecord?id=CVE-2024-5458

Regards,
Salvatore

Bug#1072340: sredird: CVE-2004-2386, format string vulnerability

[Salvatore Bonaccorso]

Hi Bastian,

On Sat, Jun 01, 2024 at 05:11:25PM +0200, Bastian Germann wrote:
> Control: notfound -1 sredird/2.1.0-1
> Control: fixed -1 2.2.1-1.1
> 
> I see that CVE-2004-2386 and maybe CVE-2004-2387 was addressed with #267098.
> The diff (one change in LogMsg and one in HandleCPCCommand) that is in that 
> bug has survived until now.
> But 2.2.2 has many more changes of the HandleCPCCommand kind: changing 
> sprintf to snprintf.
> 
> main: 2 changes.
> HandleIACCommand: 5 changes.
> HandleCPCCommand: 17 additional changes: Any of these cound be CVE-2004-2387 
> as well.
> HDBUnlockFile: 1 change.
> HDBLockFile: 7 changes.
> 
> Plus TmpStrLen is extended to 512 bytes.
> 
> Conclusion: Debian referenced both bugs as TEMP-0267098-76A1A1 before.

Perfect, thanks for the confirmation.

Regards,
Salvatore

Bug#1072366: libndp: CVE-2024-5564

[Salvatore Bonaccorso]

Source: libndp
Version: 1.8-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.6-1

Hi,

The following vulnerability was published for libndp.

CVE-2024-5564[0]:
| A vulnerability was found in libndp. This flaw allows a local
| malicious user to cause a buffer overflow in NetworkManager,
| triggered by sending a malformed IPv6 router advertisement packet.
| This issue occurred as libndp was not correctly validating the route
| length information.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-5564
https://www.cve.org/CVERecord?id=CVE-2024-5564

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1072107: libarchive: diff for NMU version 3.7.2-2.1

[Salvatore Bonaccorso]

Control: tags 1072107 + patch
Control: tags 1072107 + pending


Dear maintainer,

I've prepared an NMU for libarchive (versioned as 3.7.2-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru libarchive-3.7.2/debian/changelog libarchive-3.7.2/debian/changelog
--- libarchive-3.7.2/debian/changelog	2024-03-30 19:11:06.0 +0100
+++ libarchive-3.7.2/debian/changelog	2024-06-01 15:50:51.0 +0200
@@ -1,3 +1,12 @@
+libarchive (3.7.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix: OOB in rar e8 filter (CVE-2024-26256) (Closes: #1072107)
+  * fix: OOB in rar delta filter
+  * fix: OOB in rar audio filter
+
+ -- Salvatore Bonaccorso   Sat, 01 Jun 2024 15:50:51 +0200
+
 libarchive (3.7.2-2) unstable; urgency=medium
 
   [ Luca Boccassi ]
diff -Nru libarchive-3.7.2/debian/patches/fix-OOB-in-rar-audio-filter-2149.patch libarchive-3.7.2/debian/patches/fix-OOB-in-rar-audio-filter-2149.patch
--- libarchive-3.7.2/debian/patches/fix-OOB-in-rar-audio-filter-2149.patch	1970-01-01 01:00:00.0 +0100
+++ libarchive-3.7.2/debian/patches/fix-OOB-in-rar-audio-filter-2149.patch	2024-06-01 15:50:09.0 +0200
@@ -0,0 +1,32 @@
+From: Wei-Cheng Pan 
+Date: Mon, 29 Apr 2024 06:53:19 +0900
+Subject: fix: OOB in rar audio filter (#2149)
+Origin: https://github.com/libarchive/libarchive/commit/3006bc5d02ad3ae3c4f9274f60c1f9d2d834734b
+
+This patch ensures that `src` won't move ahead of `dst`, so `src` will
+not OOB. Similar situation like in a1cb648.
+---
+ libarchive/archive_read_support_format_rar.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/libarchive/archive_read_support_format_rar.c b/libarchive/archive_read_support_format_rar.c
+index 619ee81e2b59..4fc6626cacfd 100644
+--- a/libarchive/archive_read_support_format_rar.c
 b/libarchive/archive_read_support_format_rar.c
+@@ -3722,6 +3722,13 @@ execute_filter_audio(struct rar_filter *filter, struct rar_virtual_machine *vm)
+ memset(&state, 0, sizeof(state));
+ for (j = i; j < length; j += numchannels)
+ {
++  /*
++   * The src block should not overlap with the dst block.
++   * If so it would be better to consider this archive is broken.
++   */
++  if (src >= dst)
++return 0;
++
+   int8_t delta = (int8_t)*src++;
+   uint8_t predbyte, byte;
+   int prederror;
+-- 
+2.45.1
+
diff -Nru libarchive-3.7.2/debian/patches/fix-OOB-in-rar-delta-filter-2148.patch libarchive-3.7.2/debian/patches/fix-OOB-in-rar-delta-filter-2148.patch
--- libarchive-3.7.2/debian/patches/fix-OOB-in-rar-delta-filter-2148.patch	1970-01-01 01:00:00.0 +0100
+++ libarchive-3.7.2/debian/patches/fix-OOB-in-rar-delta-filter-2148.patch	2024-06-01 15:49:18.0 +0200
@@ -0,0 +1,36 @@
+From: Wei-Cheng Pan 
+Date: Mon, 29 Apr 2024 06:50:22 +0900
+Subject: fix: OOB in rar delta filter (#2148)
+Origin: https://github.com/libarchive/libarchive/commit/a1cb648d52f5b6d3f31184d9b6a7cbca628459b7
+
+Ensure that `src` won't move ahead of `dst`, so `src` will not OOB.
+Since `dst` won't move in this function, and we are only increasing `src`
+position, this check should be enough. It should be safe to early return
+because this function does not allocate resources.
+---
+ libarchive/archive_read_support_format_rar.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/libarchive/archive_read_support_format_rar.c b/libarchive/archive_read_support_format_rar.c
+index 79669a8f40f9..619ee81e2b59 100644
+--- a/libarchive/archive_read_support_format_rar.c
 b/libarchive/archive_read_support_format_rar.c
+@@ -3612,7 +3612,15 @@ execute_filter_delta(struct rar_filter *filter, struct rar_virtual_machine *vm)
+   {
+ uint8_t lastbyte = 0;
+ for (idx = i; idx < length; idx += numchannels)
++{
++  /*
++   * The src block should not overlap with the dst block.
++   * If so it would be better to consider this archive is broken.
++   */
++  if (src >= dst)
++return 0;
+   lastbyte = dst[idx] = lastbyte - *src++;
++}
+   }
+ 
+   filter->filteredblockaddress = length;
+-- 
+2.45.1
+
diff -Nru libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch
--- libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch	1970-01-01 01:00:00.0 +0100
+++ libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch	2024-06-01 09:42:15.0 +0200
@@ -0,0 +1,29 @@
+From: Wei-Cheng Pan 
+Date: Mon, 22 Apr 2024 01:55:41 +0900
+Subject: fix: OOB in rar e8 filter (#2135)
+Origin: https://github.com/libarchive/libarchive/commit/eb7939b24a681a04648a59cdebd386b1e9dc9237
+Bug-Debian: https://bugs.debian.org/1072107
+Bug: https://github.com/libarchive/libarchive/pull/2135
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-26256
+
+This patch fixes

Bug#1072107: libarchive: diff for NMU version 3.7.2-2.1

[Salvatore Bonaccorso]

Control: tags -1 - pending patch

Hi Peter,

On Sat, Jun 01, 2024 at 09:57:09AM +0200, Salvatore Bonaccorso wrote:
> Control: tags 1072107 + patch
> Control: tags 1072107 + pending
> 
> Hi Peter,
> 
> I've prepared an NMU for libarchive (versioned as 3.7.2-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
> 
> Made as well a MR in
> https://salsa.debian.org/debian/libarchive/-/merge_requests/6 .
> 
> libarchive requires a DSA, but see the mail from Moritz some days ago.
> This MR aims to get the ball rolling from top-down first unstable, to
> bookworm later/same time. 

I'm cancelling this, as Moritz suggested to include two more changes
in rar parsing code. Will resubmit an improved debdiff.

Regards,
Salvatore

Bug#1072340: sredird: CVE-2004-2386, format string vulnerability

[Salvatore Bonaccorso]

Hi Bastian,

On Sat, Jun 01, 2024 at 12:41:43PM +0200, Bastian Germann wrote:
> Source: sredird
> Version: 2.1.0-1
> Severity: serious
> Tags: security
> X-Debbugs-Cc: secur...@debian.org
> 
> Hi,
> 
> This is affected by CVE-2004-2386, which was marked by the Security Team as
> "NOT-FOR-US: sercd" but applies to sredird. There is a fixed version 2.2.2
> available, which I did not find in the Kermit project's download area but
> at:
> 
> http://ibiblio.org/pub/linux/system/serial/sredird-2.2.2.tar.gz
> https://sources.buildroot.net/sredird/sredird-2.2.2.tar.gz

Note, there is as well CVE-2004-2387.

There are not very specific information for both, so it's unclear if
CVE-2004-2387 and CVE-2004-2386 are addressed.

Where do you have additional information on the issues from?  Can you
pass us those?

Regards,
Salvatore

Bug#1072107: libarchive: diff for NMU version 3.7.2-2.1

[Salvatore Bonaccorso]

Control: tags 1072107 + patch
Control: tags 1072107 + pending

Hi Peter,

I've prepared an NMU for libarchive (versioned as 3.7.2-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Made as well a MR in
https://salsa.debian.org/debian/libarchive/-/merge_requests/6 .

libarchive requires a DSA, but see the mail from Moritz some days ago.
This MR aims to get the ball rolling from top-down first unstable, to
bookworm later/same time. 

Regards,
Salvatore
diff -Nru libarchive-3.7.2/debian/changelog libarchive-3.7.2/debian/changelog
--- libarchive-3.7.2/debian/changelog	2024-03-30 19:11:06.0 +0100
+++ libarchive-3.7.2/debian/changelog	2024-06-01 09:43:45.0 +0200
@@ -1,3 +1,10 @@
+libarchive (3.7.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix: OOB in rar e8 filter (CVE-2024-26256) (Closes: #1072107)
+
+ -- Salvatore Bonaccorso   Sat, 01 Jun 2024 09:43:45 +0200
+
 libarchive (3.7.2-2) unstable; urgency=medium
 
   [ Luca Boccassi ]
diff -Nru libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch
--- libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch	1970-01-01 01:00:00.0 +0100
+++ libarchive-3.7.2/debian/patches/fix-OOB-in-rar-e8-filter-2135.patch	2024-06-01 09:42:15.0 +0200
@@ -0,0 +1,29 @@
+From: Wei-Cheng Pan 
+Date: Mon, 22 Apr 2024 01:55:41 +0900
+Subject: fix: OOB in rar e8 filter (#2135)
+Origin: https://github.com/libarchive/libarchive/commit/eb7939b24a681a04648a59cdebd386b1e9dc9237
+Bug-Debian: https://bugs.debian.org/1072107
+Bug: https://github.com/libarchive/libarchive/pull/2135
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-26256
+
+This patch fixes an out-of-bound error in rar e8 filter.
+---
+ libarchive/archive_read_support_format_rar.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libarchive/archive_read_support_format_rar.c b/libarchive/archive_read_support_format_rar.c
+index 99a11d170074..266d0ee9959a 100644
+--- a/libarchive/archive_read_support_format_rar.c
 b/libarchive/archive_read_support_format_rar.c
+@@ -3615,7 +3615,7 @@ execute_filter_e8(struct rar_filter *filter, struct rar_virtual_machine *vm, siz
+   uint32_t filesize = 0x100;
+   uint32_t i;
+ 
+-  if (length > PROGRAM_WORK_SIZE || length < 4)
++  if (length > PROGRAM_WORK_SIZE || length <= 4)
+ return 0;
+ 
+   for (i = 0; i <= length - 5; i++)
+-- 
+2.45.1
+
diff -Nru libarchive-3.7.2/debian/patches/series libarchive-3.7.2/debian/patches/series
--- libarchive-3.7.2/debian/patches/series	2024-03-30 19:11:06.0 +0100
+++ libarchive-3.7.2/debian/patches/series	2024-06-01 09:42:36.0 +0200
@@ -2,3 +2,4 @@
 iso9660-hash.patch
 test-zstd-32bit.patch
 robust-error-reporting.patch
+fix-OOB-in-rar-e8-filter-2135.patch

Bug#1072112: freerdp2: CVE-2024-32658 CVE-2024-32659 CVE-2024-32660 CVE-2024-32661

[Salvatore Bonaccorso]

Source: freerdp2
Version: 2.11.5+dfsg1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for freerdp2.

CVE-2024-32658[0]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients prior to version 3.5.1 are vulnerable to out-
| of-bounds read. Version 3.5.1 contains a patch for the issue. No
| known workarounds are available.


CVE-2024-32659[1]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients prior to version 3.5.1 are vulnerable to out-
| of-bounds read if `((nWidth == 0) and (nHeight == 0))`. Version
| 3.5.1 contains a patch for the issue. No known workarounds are
| available.


CVE-2024-32660[2]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| Prior to version 3.5.1, a malicious server can crash the FreeRDP
| client by sending invalid huge allocation size. Version 3.5.1
| contains a patch for the issue. No known workarounds are available.


CVE-2024-32661[3]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients prior to version 3.5.1 are vulnerable to a
| possible `NULL` access and crash. Version 3.5.1 contains a patch for
| the issue. No known workarounds are available.


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-2024-32658
https://www.cve.org/CVERecord?id=CVE-2024-32658
[1] https://security-tracker.debian.org/tracker/CVE-2024-32659
https://www.cve.org/CVERecord?id=CVE-2024-32659
[2] https://security-tracker.debian.org/tracker/CVE-2024-32660
https://www.cve.org/CVERecord?id=CVE-2024-32660
[3] https://security-tracker.debian.org/tracker/CVE-2024-32661
https://www.cve.org/CVERecord?id=CVE-2024-32661

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1072107: libarchive: CVE-2024-26256

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.7.2-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.6.2-1

Hi,

The following vulnerability was published for libarchive.

CVE-2024-26256[0]:
| libarchive Remote Code Execution Vulnerability


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-26256
https://www.cve.org/CVERecord?id=CVE-2024-26256
[1] https://github.com/advisories/GHSA-2jc9-36w4-pmqw
[2] 
https://github.com/libarchive/libarchive/commit/eb7939b24a681a04648a59cdebd386b1e9dc9237

Regards,
Salvatore

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo unreproducible
Control: found -1 6.8.11-1

Hi,

On Mon, May 27, 2024 at 03:11:21PM +0200, Jörn Heusipp wrote:
> 
> Hello!
> 
> > I cannot reproduce this problem.
> 
> So it might be probably somewhat system-specific. I have not tried other
> i386 systems myself.
> 
> > If you still can with the recent
> > 6.8.11-1 landed in unstable,
> 
> 6.8.11-1 also crashes.

Thanks for testing! Updating the metadata.

> > you might try to bisect the changes in
> > upstream kernel to determine the breaking commit?
> 
> I'll try to do that, but it might take a couple of days until I have a
> result.
> 
> Should I report the bug upstream myself or will Debian handle this?

If you, while bisecting it can report it to upstream that would the
best way forward (please keep us in the loop so we notice when the
issue is isolated and ideally a fix available).

Thank you,

Regards,
Salvatore

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo unreproducible

Hi Jörn,

On Sat, May 18, 2024 at 09:37:03AM +0200, Jörn Heusipp wrote:
> Package: src:linux
> Version: 6.7.12-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: osm...@problemloesungsmaschine.de
> 
> Hello Debian kernel team!
> 
> 
> Linux 6.7.12-1 (686-pae) fails to boot for me on this system.
> 
> It hangs right after:
> ===
> Loading Linux 6.7.12-686-pae ...
> Loading initial ramdisk ...
> ===
> 
> Booting with 'earlyprintk=vga', I managed to capture a stack trace on video. I
> stitched together an image showing it as a whole:
> , and also attached.
> 
> Trimmed transcription (might contain typos) of the crash (I can transcribe all
> of it if really needed, but I figured the type of crash and the trace itself
> could be sufficient):
> ===
> BUG: kernel NULL pointer dereference, address: 0010
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> Oops: 0002 [#1] PREEMPT SMP NOPTI
> [...]
> EIP: __ring_buffer_alloc+0x32/0x194
> [...]
> show_regs
> __die
> page_fault_oops
> kernelmode_fixup_or_oops.constprop
> __bad_area_nosemaphore.constprop
> bad_area_nosemaphore
> do_user_addr_fault
> prb_read_valid
> exc_page_fault
> pvclock_clocksource_read_nowd
> handle_exception
> pvclock_clocksource_read_nowd
> __ring_buffer_alloc
> pvclock_clocksource_read_nowd
> __ring_buffer_alloc
> early_trace_init
> start_kernel
> i386_start_kernel
> startup_32_smp
> [...]
> ===
> 
> The line immediately before the crash reads
> "ftrace: allocated 78 pages with 4 groups".
> 
> linux 6.8.9-1 (686-pae) from unstable shows the same behaviour; it also
> crashes.
> 
> I am still running 6.6.15-2 on this box for now, which works completely fine
> (as did all Debian Testing kernels since at least the 2.6.32 days on this
> particular box). 6.7.12-1 (amd64) also works fine on all of my amd64 boxes.

I cannot reproduce this problem. If you still can with the recent
6.8.11-1 landed in unstable, you might try to bisect the changes in
upstream kernel to determine the breaking commit?

Regards,
Salvatore

Bug#1071568: closing 1071568

[Salvatore Bonaccorso]

close 1071568 535.161.08-2~deb12u1~bpo11+1
thanks

Fixed with the version accepted in bullseye-backports.

Bug#1071568: nvidia-kernel-dkms: module (from backports) fails to build with 5.10.216-1 (ABI 29 kernel) in Debian bullseye

[Salvatore Bonaccorso]

Package: nvidia-kernel-dkms
Version: 525.147.05-7~deb12u1~bpo11+2
Severity: serious
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org

Hi Andreas,

This is only for the bullseye-backports version of
525.147.05-7~deb12u1~bpo11+2 when building for 5.10.216-1 (ABI 29
kernel).

The build fails with:

make -f /usr/src/linux-headers-5.10.0-29-common/scripts/Makefile.modpost
  sed 's/ko$/o/' /var/lib/dkms/nvidia-current/525.147.05/build/modules.order | 
scripts/mod/modpost -m-o /var/lib/d
kms/nvidia-current/525.147.05/build/Module.symvers -e -i Module.symvers   -T -
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 
'rcu_read_unlock_strict'
make[3]: *** 
[/usr/src/linux-headers-5.10.0-29-common/scripts/Makefile.modpost:123: 
/var/lib/dkms/nvidia-current/525.147.05/build/Module.symvers] Error 1
make[2]: *** [/usr/src/linux-headers-5.10.0-29-common/Makefile:1783: modules] 
Error 2
make[2]: Leaving directory '/usr/src/linux-headers-5.10.0-29-amd64'
make[1]: *** [Makefile:192: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-29-common'
make: *** [Makefile:82: modules] Error 2

Regards,
Salvatore


make.log.gz
Description: application/gzip

Bug#1058890: closing 1058890

[Salvatore Bonaccorso]

close 1058890 6.1.85-1
thanks

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058890#79

Bug#1071160: git: CVE-2024-32002 CVE-2024-32004 CVE-2024-32020 CVE-2024-32021 CVE-2024-32465

[Salvatore Bonaccorso]

Source: git
Version: 1:2.43.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for git.

CVE-2024-32002[0]:
| Git is a revision control system. Prior to versions 2.45.1, 2.44.1,
| 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with
| submodules can be crafted in a way that exploits a bug in Git
| whereby it can be fooled into writing files not into the submodule's
| worktree but into a `.git/` directory. This allows writing a hook
| that will be executed while the clone operation is still running,
| giving the user no opportunity to inspect the code that is being
| executed. The problem has been patched in versions 2.45.1, 2.44.1,
| 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support
| is disabled in Git (e.g. via `git config --global core.symlinks
| false`), the described attack won't work. As always, it is best to
| avoid cloning repositories from untrusted sources.


CVE-2024-32004[1]:
| Git is a revision control system. Prior to versions 2.45.1, 2.44.1,
| 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, an attacker can prepare
| a local repository in such a way that, when cloned, will execute
| arbitrary code during the operation. The problem has been patched in
| versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.
| As a workaround, avoid cloning repositories from untrusted sources.


CVE-2024-32020[2]:
| Git is a revision control system. Prior to versions 2.45.1, 2.44.1,
| 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up
| hardlinking files into the target repository's object database when
| source and target repository reside on the same disk. If the source
| repository is owned by a different user, then those hardlinked files
| may be rewritten at any point in time by the untrusted user. Cloning
| local repositories will cause Git to either copy or hardlink files
| of the source repository into the target repository. This
| significantly speeds up such local clones compared to doing a
| "proper" clone and saves both disk space and compute time. When
| cloning a repository located on the same disk that is owned by a
| different user than the current user we also end up creating such
| hardlinks. These files will continue to be owned and controlled by
| the potentially-untrusted user and can be rewritten by them at will
| in the future. The problem has been patched in versions 2.45.1,
| 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.


CVE-2024-32021[3]:
| Git is a revision control system. Prior to versions 2.45.1, 2.44.1,
| 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local
| source repository that contains symlinks via the filesystem, Git may
| create hardlinks to arbitrary user-readable files on the same
| filesystem as the target repository in the `objects/` directory.
| Cloning a local repository over the filesystem may creating
| hardlinks to arbitrary user-owned files on the same filesystem in
| the target Git repository's `objects/` directory. When cloning a
| repository over the filesystem (without explicitly specifying the
| `file://` protocol or `--no-local`), the optimizations for local
| cloning will be used, which include attempting to hard link the
| object files instead of copying them. While the code includes checks
| against symbolic links in the source repository, which were added
| during the fix for CVE-2022-39253, these checks can still be raced
| because the hard link operation ultimately follows symlinks. If the
| object on the filesystem appears as a file during the check, and
| then a symlink during the operation, this will allow the adversary
| to bypass the check and create hardlinks in the destination objects
| directory to arbitrary, user-readable files. The problem has been
| patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2,
| and 2.39.4.


CVE-2024-32465[4]:
| Git is a revision control system. The Git project recommends to
| avoid working in untrusted repositories, and instead to clone it
| first with `git clone --no-local` to obtain a clean copy. Git has
| specific protections to make that a safe operation even with an
| untrusted source repository, but vulnerabilities allow those
| protections to be bypassed. In the context of cloning local
| repositories owned by other users, this vulnerability has been
| covered in CVE-2024-32004. But there are circumstances where the
| fixes for CVE-2024-32004 are not enough: For example, when obtaining
| a `.zip` file containing a full copy of a Git repository, it should
| not be trusted by default to be safe, as e.g. hooks could be
| configured to run within the context of that repository. The problem
| has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1,
| 2.40.2, and 2.39.4. As a workaround, avoid using Git in repositories
| that have been obtained via archives from untrusted sources.


I

Bug#1070395: closing 1070395, found 1070395 in 1.11.1-2.1

[Salvatore Bonaccorso]

close 1070395 1.11.1-4
found 1070395 1.11.1-2.1
thanks

Bug#1070395: tinyproxy: CVE-2023-40533 CVE-2023-49606

[Salvatore Bonaccorso]

Control: retitle -1 tinyproxy: CVE-2023-49606

Hi,

CVE-2023-40533 as a duplicate of CVE-2022-40468 .

Regards,
Salvatore

Bug#1070711: python-werkzeug: CVE-2024-34069

[Salvatore Bonaccorso]

Source: python-werkzeug
Version: 3.0.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-werkzeug.

CVE-2024-34069[0]:
| Werkzeug is a comprehensive WSGI web application library. The
| debugger in affected versions of Werkzeug can allow an attacker to
| execute code on a developer's machine under some circumstances. This
| requires the attacker to get the developer to interact with a domain
| and subdomain they control, and enter the debugger PIN, but if they
| are successful it allows access to the debugger even if it is only
| running on localhost. This also requires the attacker to guess a URL
| in the developer's application that will trigger the debugger. This
| vulnerability is fixed in 3.0.3.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-34069
https://www.cve.org/CVERecord?id=CVE-2024-34069
[1] https://github.com/pallets/werkzeug/security/advisories/GHSA-2g68-c3qc-8985
[2] 
https://github.com/pallets/werkzeug/commit/71b69dfb7df3d912e66bab87fbb1f21f83504967
[3] 
https://github.com/pallets/werkzeug/commit/890b6b62634fa61224222aee31081c61b054ff01

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070710: python-html-sanitizer: CVE-2024-34078: Arbitrary HTML present after sanitization because of unicode normalization

[Salvatore Bonaccorso]

Source: python-html-sanitizer
Version: 2.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-html-sanitizer.

CVE-2024-34078[0]:
| html-sanitizer is an allowlist-based HTML cleaner. If using
| `keep_typographic_whitespace=False` (which is the default), the
| sanitizer normalizes unicode to the NFKC form at the end. Some
| unicode characters normalize to chevrons; this allows specially
| crafted HTML to escape sanitization. The problem has been fixed in
| 2.4.2.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-34078
https://www.cve.org/CVERecord?id=CVE-2024-34078
[1] 
https://github.com/matthiask/html-sanitizer/security/advisories/GHSA-wvhx-q427-fgh3
[2] 
https://github.com/matthiask/html-sanitizer/commit/48db42fc5143d0140c32d929c46b802f96913550

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070369: sssd: CVE-2023-3758

[Salvatore Bonaccorso]

Source: sssd
Version: 2.9.4-2
Severity: grave
Tags: security upstream
Forwarded: https://github.com/SSSD/sssd/pull/7302
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sssd.

CVE-2023-3758[0]:
| A race condition flaw was found in sssd where the GPO policy is not
| consistently applied for authenticated users. This may lead to
| improper authorization issues, granting or denying access to
| resources inappropriately.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3758
https://www.cve.org/CVERecord?id=CVE-2023-3758
[1] https://github.com/SSSD/sssd/pull/7302
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2223762
[3] 
https://github.com/SSSD/sssd/commit/e1bfbc2493c4194988acc3b2413df3dde0735ae3 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070004: ruby-sidekiq: CVE-2024-32887

[Salvatore Bonaccorso]

Package: ruby-sidekiq
Version: 7.2.1+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

The following vulnerability was published for ruby-sidekiq.

It only affects the experimental version, as the issue was introduced
in 7.2.0 an fixed upstream in 7.2.4. Should not land into unstable, so
filling with RC severity.

CVE-2024-32887[0]:
| Sidekiq is simple, efficient background processing for Ruby. Sidekiq
| is reflected XSS vulnerability. The value of substr parameter is
| reflected in the response without any encoding, allowing an attacker
| to inject Javascript code into the response of the application.  An
| attacker could exploit it to target users of the Sidekiq Web UI.
| Moreover, if other applications are deployed on the same domain or
| website as Sidekiq, users of those applications could also be
| affected, leading to a broader scope of compromise. Potentially
| compromising their accounts, forcing the users to perform sensitive
| actions, stealing sensitive data, performing CORS attacks,
| defacement of the web application, etc. This issue has been patched
| in version 7.2.4.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-32887
https://www.cve.org/CVERecord?id=CVE-2024-32887
[1] https://github.com/sidekiq/sidekiq/security/advisories/GHSA-q655-3pj8-9fxq

Regards,
Salvatore

Bug#1069968: ruby3.2: CVE-2024-27282

[Salvatore Bonaccorso]

Source: ruby3.2
Version: 3.2.3-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src;ruby3.1 3.1.2-8
Control: retitle -2 ruby3.1: CVE-2024-27282
Control: found -2 3.1.2-7

Hi,

The following vulnerability was published for ruby.

CVE-2024-27282[0]:
| Arbitrary memory address read vulnerability with Regex search


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27282
https://www.cve.org/CVERecord?id=CVE-2024-27282
[1] 
https://www.ruby-lang.org/en/news/2024/04/23/arbitrary-memory-address-read-regexp-cve-2024-27282/
[2] https://github.com/ruby/ruby/commit/989a2355808a63fc45367785c82ffd46d18c900a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore