Bug#1071973: qt6-networkauth: CVE-2024-36048

[Salvatore Bonaccorso]

Source: qt6-networkauth
Version: 6.4.2-5
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:qtnetworkauth-everywhere-src 5.15.13-2
Control: retitle -2 qtnetworkauth-everywhere-src: CVE-2024-36048

Hi,

The following vulnerability was published for QAbstractOAuth.

CVE-2024-36048[0]:
| QAbstractOAuth in Qt Network Authorization in Qt before 5.15.17, 6.x
| before 6.2.13, 6.3.x through 6.5.x before 6.5.6, and 6.6.x through
| 6.7.x before 6.7.1 uses only the time to seed the PRNG, which may
| result in guessable values.


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-36048
https://www.cve.org/CVERecord?id=CVE-2024-36048
[1] https://codereview.qt-project.org/c/qt/qtnetworkauth/+/560317
[2] https://codereview.qt-project.org/c/qt/qtnetworkauth/+/560368

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1071972: openssl: CVE-2024-4603

[Salvatore Bonaccorso]

Source: openssl
Version: 3.2.1-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for openssl.

In avoidance of doupt, no DSA is needed, filling the bug for BTS
tracking and it can simply be fixed in the next round of rebasing
openssl (IMHO).

CVE-2024-4603[0]:
| Issue summary: Checking excessively long DSA keys or parameters may
| be very slow.  Impact summary: Applications that use the functions
| EVP_PKEY_param_check() or EVP_PKEY_public_check() to check a DSA
| public key or DSA parameters may experience long delays. Where the
| key or parameters that are being checked have been obtained from an
| untrusted source this may lead to a Denial of Service.  The
| functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
| various checks on DSA parameters. Some of those computations take a
| long time if the modulus (`p` parameter) is too large.  Trying to
| use a very large modulus is slow and OpenSSL will not allow using
| public keys with a modulus which is over 10,000 bits in length for
| signature verification. However the key and parameter check
| functions do not limit the modulus size when performing the checks.
| An application that calls EVP_PKEY_param_check() or
| EVP_PKEY_public_check() and supplies a key or parameters obtained
| from an untrusted source could be vulnerable to a Denial of Service
| attack.  These functions are not called by OpenSSL itself on
| untrusted DSA keys so only applications that directly call these
| functions may be vulnerable.  Also vulnerable are the OpenSSL pkey
| and pkeyparam command line applications when using the `-check`
| option.  The OpenSSL SSL/TLS implementation is not affected by this
| issue.  The OpenSSL 3.0 and 3.1 FIPS providers are affected by 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-4603
https://www.cve.org/CVERecord?id=CVE-2024-4603
[1] https://www.openssl.org/news/secadv/20240516.txt

Please adjust the affected versions in the BTS as needed.

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#1050256: AppArmor breaks locking non-fs Unix sockets

[Salvatore Bonaccorso]

Hi,

For those watching this bug: John has prepared backports in his tree,
with both approaches:

https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-two-patch-1780227

and

https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-backport-1780227

(but with the open question which one will be submitted for stable.
>From upstream stable point of view probably the two patch backport
approach would be the preferred one).

Regards,
Salvatore

Bug#1070998: bookworm-pu: package fossil/2.24-5~deb11u1

[Salvatore Bonaccorso]

Hi Bastien,

On Sun, May 12, 2024 at 05:47:31PM +, Bastien Roucariès wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> X-Debbugs-Cc: fos...@packages.debian.org
> Control: affects -1 + src:fossil
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> this bug was opened by previous arrangement with maintainer.
> 
> [ Reason ]
> fossil is affected by a regression due to a security update of apache
> CVE-2024-24795. Backport was choosen
> because upstream does not document all commit needed for fixing the 
> regression.

Disclaimer, not SRM so this is not an authoritative answer.

But that means that as well packaing changes beween 1:2.21-1 and the
proposed one are included. Are all of those allowed to be done or
should you individually revert some changes?

E.g. there is 

  * Bump policy
  * Build depend on pkgconfig instead of obsolete pkg-config
and
  * Oops, typo: pkgconf

which might indeed be fine. But should defintitively be checked.

Regards,
Salvatore

Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Salvatore Bonaccorso]

Hi Lee,

(disclaimer, not a member of the release team)

On Fri, May 10, 2024 at 12:15:56PM +0200, Lee Garrett wrote:
> I have just pushed some meta-data updates, and also a change that fixes
> CVE-2023-4237 in this package. See the commit logs here:
> 
> https://salsa.debian.org/python-team/packages/ansible/-/commits/debian/bookworm-proposed/

My understanding is that SRM would like to have a debdiff posted to
the list with the changes. I realize the previous one was 10M big, and
so actually might have not made to the list, and so not on the radar
of the SRM. 

Stuff might be as well filtered out if needed from the debdiff, and
explained in the mail.

As your proposed update covers as well a CVE fix, that would be great
if it can make it to the next point release.

Regards,
Salvatore

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[Salvatore Bonaccorso]

Hi John,

On Fri, May 24, 2024 at 01:57:01PM -0400, John Waffle wrote:
> Hello,
> 
> I was thinking about this a bit more and I had a question,
> 
> > Let me as well elaborate on the "ingored". This comes as the binary
> packages built from the *vulnerable* source, there is no point to force an
> update in bookworm and older.
> 
> It sounds like Debian uses the "ignored" state to mean "this bug does not
> affect the Debian package".
> 
> Is there another state that's used to indicate "won't fix"? Can we assume
> that "ignored" always means "won't fix"? Or can "ignored" mean either thing
> and we'd have to look in the notes to know for sure?

Thanks for the query.
https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
explains how  is to be interpreted when encountered. I think
security-scanner encountering it can classify it accordingly so that
no flag is raised.

Hope that helps,

Regards,
Salvatore

Bug#1071593: requests: CVE-2024-35195

[Salvatore Bonaccorso]

Source: requests
Version: 2.31.0+dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/psf/requests/pull/6655
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for requests.

CVE-2024-35195[0]:
| Requests is a HTTP library. Prior to 2.32.0, when making requests
| through a Requests `Session`, if the first request is made with
| `verify=False` to disable cert verification, all subsequent requests
| to the same host will continue to ignore cert verification
| regardless of changes to the value of `verify`. This behavior will
| continue for the lifecycle of the connection in the connection pool.
| This vulnerability is fixed in 2.32.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-35195
https://www.cve.org/CVERecord?id=CVE-2024-35195
[1] https://github.com/psf/requests/security/advisories/GHSA-9wx4-h78v-vm56
[2] https://github.com/psf/requests/pull/6655
[3] 
https://github.com/psf/requests/commit/c0813a2d910ea6b4f8438b91d315b8d181302356

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate

[Salvatore Bonaccorso]

Hi Richard,

On Mon, May 20, 2024 at 09:27:24AM +, Richard Kojedzinszky wrote:
> Package: src:linux
> Version: 6.1.90-1
> Severity: normal
> X-Debbugs-Cc: richard+debian+bugrep...@kojedz.in
> 
> Dear Maintainer,
> 
> I am running kubernetes on debian, and pods are mounting multiple nfs
> shares. I am running dovecot processes in PODs, which receive mails from
> the internet, and also serves as imap server for clients. I am
> monitoring my mail system by sending mails periodically (15 seconds) and
> also downloading them via imap. I found a few times that some dovecot process
> stuck in D state, a reboot was always needed to recover from that state.
> 
> Unfortunately, I was not able to trigger the bug really fast, I dont
> really know what operations does dovecot issue and in what order to trigger
> this behavior. So until I get closer, I've set up a similar, but smaller
> environment with just a single dovecot process, and it also does the
> same work, delivering only test mails locally, and serving them via imap
> to the monitoring client, storing everything on NFS. Fortunately, this also
> triggers the bug, after a few hours one of the dovecot processes is stuck
> in D state. Kernel also shows blocked state:

As you seem in the lucky position to be able to trigger the issue in a
more localized setup, might you:

- try as well more recent kernels from upper suites (6.8.9-1 in
  unstable would be ideal to check if the issue is there as well).
- I did read you cannot trigger with 5.15. If you build 6.1.90 from
  upstream without Debian patches I assume you can trigger the issue
  likewise? If so could you bisect the changes introducing the issue?
  This is a cumbersome process in particular if you need few hours to
  trigger it  So maybe the following point could be done first:
- Can you report the issue to the linux-nfs list, keeping us in the
  loop?

Regards,
Salvatore

Bug#1070159: i915: CPU usage spikes with monitor powered down or unplugged

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Wed, May 01, 2024 at 10:06:51AM +0800, Gedalya wrote:
> Package: src:linux
> Version: 6.7.12-1
> Severity: normal
> 
> Hello,
> 
> I have a computer with an Intel i3-9100 CPU, using the integrated graphics, 
> no graphic session running, and a monitor plugged in to the DVI port.
> 
> The following command executed upon startup:
> setterm --term linux --blank 1
> 
> After one minute of console inactivity the monitor is actually suspended, and 
> I get the following effect every ~20 seconds:
> 
> # turbostat --interval 1 --show 
> PkgWatt,CorWatt,Avg_MHz,Busy%,Bzy_MHz,IPC,IRQ,CoreTmp,PkgTmp,POLL,POLL%
> 
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 2 0.20800 0.3857  0   0.0031  31  0.35
> 0.11
> 1 0.11800 0.229   0   0.0030  31  0.35
> 0.11
> 2 0.28800 0.2616  0   0.0030
> 1 0.08800 0.308   0   0.0031
> 3 0.34800 0.5524  0   0.0031
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 3233  81.25   39780.063782142889  78.95   35  34  19.93   
> 19.78
> 3396  85.32   39800.06273136309   78.63   34  34  19.91   
> 19.77
> 3171  79.77   39750.06223 35550   79.02   32
> 3170  79.67   39790.06212 35545   79.05   33
> 3191  80.23   39770.06616 35485   79.01   35
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 2 0.1413970.3157  0   0.0032  32  0.38
> 0.13
> 1 0.0813310.1710  0   0.0030  32  0.38
> 0.13
> 2 0.2111420.2216  0   0.0030
> 1 0.0521290.2210  0   0.0031
> 3 0.2014940.4721  0   0.0032
> 
> Or, with .5 second interval:
> 
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 3 0.32800 0.4343  0   0.0030  30  0.39
> 0.16
> 2 0.27800 0.3111  0   0.0029  30  0.39
> 0.16
> 1 0.14800 0.279   0   0.0028
> 5 0.62800 0.2818  0   0.0029
> 2 0.26800 0.985   0   0.0030
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 1373  35.07   39120.06752 31036   34.45   38  38  8.30
> 8.11
> 1370  34.97   39180.0651  772334.44   38  38  8.29
> 8.10
> 1374  35.36   38860.06533 788534.29   37
> 1372  35.06   39140.0651  771934.48   37
> 1371  34.88   39320.06117 770934.48   38
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 3626  90.58   40030.06208180119   88.33   39  39  21.97   
> 21.82
> 3565  89.12   40000.06120 19931   88.44   39  39  21.97   
> 21.82
> 3788  94.46   40110.06150320358   88.02   38
> 3565  89.13   40000.06123 19930   88.43   39
> 3584  89.59   40010.06335 19900   88.42   39
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 1477  36.91   40030.06987 31849   35.03   32  32  9.67
> 9.46
> 1417  35.45   39980.0656  792235.11   30  32  9.67
> 9.47
> 1639  40.76   40220.06705 810134.92   29
> 1420  35.54   39960.0664  792035.09   30
> 1434  35.90   39940.06162 790635.06   32
> Avg_MHz   Busy%   Bzy_MHz IPC IRQ POLLPOLL%   CoreTmp PkgTmp  
> PkgWatt CorWatt
> 2 0.23925 0.4622  0   0.0030  30  0.36
> 0.11
> 2 0.1610590.307   0   0.0029  30  0.36
> 0.11
> 1 0.0710360.302   0   0.0029
> 4 0.47867 0.2612  0   0.0030
> 2 0.20911 1.091   0   0.0030
> 
> 
> Nothing is seen in `top`. I can see a brief ~20 watt increase in power 
> consuption reported by the UPS.
> 
> There is no issue while the display is active.
> If the monitor is unplugged these spikes occur every 20 seconds, even if no 
> blanking/suspend is enabled.
> As long as the monitor is plugged in, and the display is not suspended on the 
> computer side, the issue doesn't occur even if the monitor is powered off.
> 
> With the i915 driver blacklisted the display can not be suspended, it is only 
> blanked. The CPU spikes do not occur at all, whether the display is active, 
> blanked or unplugged.
> 
> The behavior is the same with linux 6.1.85 from bookworm.
> 
> # 

Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition

[Salvatore Bonaccorso]

Control: reassign -1 src:systemd

On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote:
> Package: src:linux
> Version: 6.8.9-1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device 
> fails
> to mount the root partition. I just tried the kernel from sid and it seems 
> indeed \
> affected. The 6.7 kernel from trixie is instead booting fine even after
> regenerating all initrds.
> 
> According to bl...@debian.org, this is likely due to
> https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66
> 
> See https://lwn.net/Articles/973997/

The deprecation was there for a while indeed and dropped by upstream
for 6.8-rc1. But it looks systemd is adressing this with

https://github.com/systemd/systemd/commit/e3828d7103a99a15a1e947ba3063294ead590631

As we wont apply a local Debian patch unless upstream Linux decides to
facilitate this by adding a noop option back, then I think it's best
to reassign this bug to systemd and close it once the above change is
applied.

Regards,
Salvatore

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[Salvatore Bonaccorso]

Hi John,

On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote:
> This report came from a free tool, trivy, I filed a Github discussion about
> it here: https://github.com/aquasecurity/trivy/discussions/6722

Thanks a lot for bringing that upstream.

So to add some additional datapoint: The issue araises here by maybe
thinking zlib refers to the binary package produced. It is correct,
for the binary package zlib then indeed you would not be vulnerable. 

Let me as well elaborate on the "ingored". This comes as the binary
packages built from the *vulnerable* source, there is no point to
force an update in bookworm and older.

I hope this all get a better picture now on the CVE. If you still have
questions feel free to ask.

Regards,
Salvatore

Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?

[Salvatore Bonaccorso]

Hi,

On Fri, May 17, 2024 at 10:43:26AM -0400, John Waffle wrote:
> Package: zlib
> Version: 1:1.2.13.dfsg-1
> 
> Related bug reports:
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056718
> 
> These were marked as resolved but it seems like I'm getting some
> contradictory information.
> 
> - The zlib package page https://tracker.debian.org/pkg/zlib says that
> CVE-2023-45853 
> is ignored, what is the basis for ignoring this CVE?
> - Is there a plan to backport zlib 1:1.3.dfsg-3.1 to bookworm? It looks
> like it's currently in trixie
> 
> The maintainer of zlib said this in a comment
> https://github.com/madler/zlib/pull/843#issuecomment-2050417533
> 
> > Sigh. I tried.
> 
> > It is this page:
> https://security-tracker.debian.org/tracker/CVE-2023-45853 , that
> incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no
> minizip code in it whatsoever. (I verified that by downloading it and
> listing the external symbols in the .so file.) I managed to reach someone
> at debian.org who seems to be in control of that page, but instead of
> fixing the page, they defended it, even though it's wrong.
> 
> Can a Debian maintainer elaborate on this? Do the Debian maintainers feel
> like this version of zlib is vulnerable or not?
> 
> If the Debian maintainers could confirm that this is not a real
> vulnerability, maybe then we can get trivy to stop flagging this as a
> critical vulnerability in their scan. This is a rather big problem because
> a lot of images use Debian (bookworm specifically) and a lot of base images
> (e.g. nginx) are getting flagged for this.

Again, the notes explain the tracking; The zlib is *source* in the
security-tracker not the binary package produced. Thus the entry reads
as:

- zlib 1:1.3.dfsg-2 (bug #1054290)
[bookworm] - zlib  (contrib/minizip not built and producing 
binary packages)
[bullseye] - zlib  (contrib/minizip not built and producing 
binary packages)
[buster] - zlib  (contrib/minizip not built and producing 
binary packages)

is there in the wording which you think needs improvement?

Why does your security-scanner not consider the information gathered
by the security-tracker including the 'ignored' state there? Can you
bring that to your vendor of the security scanner?

Regards,
Salvatore

Bug#1071163: sogo: CVE-2024-34462

[Salvatore Bonaccorso]

Source: sogo
Version: 5.10.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sogo.

CVE-2024-34462[0]:
| Alinto SOGo through 5.10.0 allows XSS during attachment preview.


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-34462
https://www.cve.org/CVERecord?id=CVE-2024-34462
[1] 
https://github.com/Alinto/sogo/commit/2e37e59ed140d4aee0ff2fba579ca5f83f2c5920

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1071162: libxml2: CVE-2024-34459

[Salvatore Bonaccorso]

Source: libxml2
Version: 2.9.14+dfsg-1.3
Severity: normal
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libxml2/-/issues/720
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libxml2.

CVE-2024-34459[0]:
| An issue was discovered in xmllint (from libxml2) before 2.11.8 and
| 2.12.x before 2.12.7. Formatting error messages with xmllint
| --htmlout can result in a buffer over-read in
| xmlHTMLPrintFileContext in xmllint.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-34459
https://www.cve.org/CVERecord?id=CVE-2024-34459
[1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/720
[2] 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/8ddc7f13337c9fe7c6b6e616f404b0fffb8a5145
 (2.11.8)
[3] 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/2876ac5392a4e891b81e40e592c3ac6cb46016ce
 (2.12.7)

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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.

Bug#1070851: glib2.0: minor memory leak after fixing CVE-2024-34397

[Salvatore Bonaccorso]

Hi Simon,

On Fri, May 10, 2024 at 02:40:48PM +0100, Simon McVittie wrote:
> Source: glib2.0
> Version: 2.74.6-2+deb12u1
> Severity: minor
> Tags: patch fixed-upstream
> X-Debbugs-Cc: secur...@debian.org
> Control: found -1 2.79.0+git20240110~g38f5ba3c-1
> Control: found -1 2.66.8-1+deb11u2
> Control: fixed -1 2.80.2-1
> 
> While applying the CVE-2024-34397 fixes to glib2.0 in (old)stable,
> I backported an upstream bug fix from GLib 2.79.x to fix a possible
> use-after-free, which had gone undetected in older versions, but caused
> intermittent failures in the new test coverage that I added to reproduce
> CVE-2024-34397.
> 
> It turns out that this bug fix is not 100% correct, and causes a rare
> memory leak: if a program replaces a non-NULL message body with a different
> non-NULL message body, the first argument of the old message body is leaked.
> This has now been fixed upstream and will be in 2.80.3, and I backported
> the fix in 2.80.2-1 (uploaded to unstable today).
> 
> My current understanding is that this will not affect
> typical applications, and only applications that call
> g_dbus_connection_add_filter() and use it to edit incoming or outgoing
> messages in-place will normally be affected. This is not a common pattern,
> and the only real-world use I'm aware of is that stretch's gdm3 had a hack
> that used this to work around an incompatibility between jessie and stretch
> versions' D-Bus APIs during upgrade.
> 
> This is technically a regression in a security update, so I'm cc'ing
> the security team, but I imagine they will not want to update the DSA
> for this. My inclination is to wait for a few days to see whether
> there are any other regressions; if yes, take the opportunity to
> fix this leak at the same time; and otherwise, propose an upload to
> (old)stable-proposed-updates fixing the memory leak.

Right. If we can avoid doing another regression update since this
looks minor, and batch it instead in the point rleases that would be
preferable. Plan sounds good.

Regards,
Salvatore

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Salvatore Bonaccorso]

Hi Roland,

On Fri, May 10, 2024 at 11:18:17AM +0200, Roland Rosenfeld wrote:
> Control: fixed -1 6.1.90+1
> 
> In the meantime I upgraded to linux-image-6.1.0-21-amd64 (6.1.90+1).
> With this version the issue is solved for me.

Thanks for confirming. I in fact missed to add the bug closer for this
in the changelog once the upstream patch got indeed backported as well
to the 6.1.y series.

Regards,
Salvatore

Bug#1070793: security.debian.org: Hibernate does not work from KDE Plasma menu. System does not power off.

[Salvatore Bonaccorso]

Control: reassign -1 src:linux 5.10.216-1

Hi

The report is very vague, but I assume it's about the kernel update
recently released as DSA, so reassigning it to src:linux. 

Can you please provide more information. Is this a regression from
5.10.209-2 to 5.10.216-1?

It might be helpful to provide as well system logs on the failed
hibernation.

Regards,
Salvatore

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#1070786: arping: please add support for loong64

[Salvatore Bonaccorso]

Control: tags -1 + upstream
Control: forwarded -1 https://github.com/ThomasHabets/arping/pull/54

Hi,

This is upstream in 
https://github.com/ThomasHabets/arping/commit/99b5445cda5da420983ce1fe4ecd550e9638d523

Regards,
Salvatore

Bug#1070739: bookworm-pu: package python-glance-store/4.1.0-4

[Salvatore Bonaccorso]

Hi,

On Wed, May 08, 2024 at 09:52:01AM +0200, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: python-glance-st...@packages.debian.org
> Control: affects -1 + src:python-glance-store
> 
> [ Reason ]
> I would like to update python-glance-store/4.1.0-4 to
> python-glance-store/4.1.1-1+deb12u1 to address CVE-2024-1141
> (aka: #1063795).

Should that be 4.1.1-0+deb12u1 instead? (I do know that 4.1.1-1 was
never in the archive ,but that makes sure it sorts before 4.1.1-1).

Regards,
Salvatore

Bug#1068112: Accepted pcp 6.2.1-1 (source arm64 all) into unstable

[Salvatore Bonaccorso]

Source: pcp
Source-Version: 6.2.1-1

On Tue, May 07, 2024 at 06:03:03PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Wed, 10 Apr 2024 09:14:46 +1100
> Source: pcp
> Binary: libpcp-archive1 libpcp-archive1-dev libpcp-gui2 libpcp-gui2-dev 
> libpcp-import-perl libpcp-import1 libpcp-import1-dev libpcp-logsummary-perl 
> libpcp-mmv-perl libpcp-mmv1 libpcp-mmv1-dev libpcp-pmda-perl libpcp-pmda3 
> libpcp-pmda3-dev libpcp-trace2 libpcp-trace2-dev libpcp-web1 libpcp-web1-dev 
> libpcp3 libpcp3-dev pcp pcp-conf pcp-doc pcp-export-pcp2elasticsearch 
> pcp-export-pcp2graphite pcp-export-pcp2influxdb pcp-export-pcp2json 
> pcp-export-pcp2spark pcp-export-pcp2xlsx pcp-export-pcp2xml 
> pcp-export-pcp2zabbix pcp-export-zabbix-agent pcp-gui pcp-import-collectl2pcp 
> pcp-import-ganglia2pcp pcp-import-iostat2pcp pcp-import-mrtg2pcp 
> pcp-import-sar2pcp pcp-import-sheet2pcp pcp-pmda-infiniband pcp-testsuite 
> pcp-zeroconf python3-pcp
> Architecture: source arm64 all
> Version: 6.2.1-1
> Distribution: unstable
> Urgency: low
> Maintainer: PCP Development Team 
> Changed-By: Nathan Scott 
> Description:
>  libpcp-archive1 - Performance Co-Pilot archive writing library
>  libpcp-archive1-dev - Performance Co-Pilot archive writing library and 
> headers
>  libpcp-gui2 - Performance Co-Pilot graphical client tools library
>  libpcp-gui2-dev - Performance Co-Pilot graphical client tools library and 
> headers
>  libpcp-import-perl - Performance Co-Pilot log import Perl module
>  libpcp-import1 - Performance Co-Pilot data import library
>  libpcp-import1-dev - Performance Co-Pilot data import library and headers
>  libpcp-logsummary-perl - Performance Co-Pilot historical log summary module
>  libpcp-mmv-perl - Performance Co-Pilot Memory Mapped Value Perl module
>  libpcp-mmv1 - Performance Co-Pilot Memory Mapped Value client library
>  libpcp-mmv1-dev - Performance Co-Pilot Memory Mapped Value library and 
> headers
>  libpcp-pmda-perl - Performance Co-Pilot Domain Agent Perl module
>  libpcp-pmda3 - Performance Co-Pilot Domain Agent library
>  libpcp-pmda3-dev - Performance Co-Pilot Domain Agent library and headers
>  libpcp-trace2 - Performance Co-Pilot application tracing library
>  libpcp-trace2-dev - Performance Co-Pilot application tracing library and 
> headers
>  libpcp-web1 - Performance Co-Pilot data import library
>  libpcp-web1-dev - Performance Co-Pilot web tooling
>  libpcp3- Performance Co-Pilot library
>  libpcp3-dev - Performance Co-Pilot library and headers
>  pcp- System level performance monitoring and performance management
>  pcp-conf   - Performance Co-Pilot runtime configuration
>  pcp-doc- Documentation and tutorial for the Performance Co-Pilot
>  pcp-export-pcp2elasticsearch - Tool for exporting data from PCP to 
> Elasticsearch
>  pcp-export-pcp2graphite - Tool for exporting data from PCP to Graphite
>  pcp-export-pcp2influxdb - Tool for exporting data from PCP to InfluxDB
>  pcp-export-pcp2json - Tool for exporting data from PCP to JSON
>  pcp-export-pcp2spark - Tool for exporting data from PCP to Apache Spark
>  pcp-export-pcp2xlsx - Tool for exporting data from PCP to Excel spreadsheets
>  pcp-export-pcp2xml - Tool for exporting data from PCP to XML
>  pcp-export-pcp2zabbix - Tool for exporting data from PCP to Zabbix
>  pcp-export-zabbix-agent - Module for exporting PCP metrics to Zabbix agent
>  pcp-gui- Visualisation tools for the Performance Co-Pilot toolkit
>  pcp-import-collectl2pcp - Tool for importing data from collectl into PCP 
> archive logs
>  pcp-import-ganglia2pcp - Tool for importing data from ganglia into PCP 
> archive logs
>  pcp-import-iostat2pcp - Tool for importing data from iostat into PCP archive 
> logs
>  pcp-import-mrtg2pcp - Tool for importing data from MRTG into PCP archive logs
>  pcp-import-sar2pcp - Tool for importing data from sar into PCP archive logs
>  pcp-import-sheet2pcp - Tool for importing data from a spreadsheet into PCP 
> archive logs
>  pcp-pmda-infiniband - Infiniband performance metrics domain agent (PMDA)
>  pcp-testsuite - Performance Co-Pilot (PCP) Test Suite
>  pcp-zeroconf - Performance Co-Pilot (PCP) Zeroconf Package
>  python3-pcp - Performance Co-Pilot Python3 PMAPI module
> Closes: 1068389
> Changes:
>  pcp (6.2.1-1) unstable; urgency=low
>  .
>* New release (full details in CHANGELOG).
>* Drop BCC metrics as python3-bpfcc is no more (closes: #1068389)
> Checksums-Sha1:
>  637cc70fcadc359ed918ad06782105b07a4a49d3 5167 pcp_6.2.1-1.dsc
>  0937cbb81aa51d58f88a655051139b187bfe40a6 52262174 pcp_6.2.1.orig.tar.gz
>  4169185a601ba722e120739099ef540c604d3fcc 26832 pcp_6.2.1-1.debian.tar.xz
>  f7137a18c5eb173c8ac2d5f388229ec8fcd5f6f0 136968 
> libpcp-archive1-dev_6.2.1-1_arm64.deb
>  5b243d0c7aee81c85db0e5c6e67f0acf50cabcd0 123776 
> libpcp-archive1_6.2.1-1_arm64.deb
>  fe81f37f52d4b2624c42ef2876d5b3578612f2aa 126244 
> libpcp-gui2-dev_6.2.1-1_arm64.deb
>  

Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Hi,

On Tue, May 07, 2024 at 06:35:06PM +, Kari Lempiäinen wrote:
> Hi,
> 
> Looks like this fixed the problem. I ran a couple of backup jobs to
> cifs-mounted shares and no error messages so far. Thanks!

Thanks for the confirmation!

Regards,
Salvatore

Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Tito,

On Tue, May 07, 2024 at 10:19:44AM +0200, Tito Ragusa wrote:
> Package: src:linux
> Version: 6.1.90-1
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>Rebooting the box after kernel package upgrade
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>Nothing
> 
>* What was the outcome of this action?
>  
>Nothing 
> 
>* What outcome did you expect instead?
> 
>Rebooting without traces in the logs
>  
> -- Package-specific info:
> ** Version:
> Linux version 6.1.0-21-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
> 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
> PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03)
> 
> ** Command line:
> BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64 
> root=UUID=a75e6ad5-37fc-4f69-9361-f94d6c0e5d2f ro net.ifnames=0 apparmor=0 
> selinux=0 noresume consoleblank=0 console=tty1
> 
> ** Tainted: WOE (12800)
>  * kernel issued warning
>  * externally-built ("out-of-tree") module was loaded
>  * unsigned module was loaded
> 
> ** Kernel log:
>   May  7 08:10:12 cerberus kernel: [   76.203881] [ cut here 
> ]
> May  7 08:10:12 cerberus kernel: [   76.203895] WARNING: CPU: 3 PID: 0 at 
> net/bridge/br_netfilter_hooks.c:622 br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> May  7 08:10:12 cerberus kernel: [   76.203911] Modules linked in: ctr ccm 
> nf_tables xt_nat xt_recent xt_geoip(OE) xt_NFQUEUE xt_mark xt_CT xt_tcpudp 
> xt_helper nf_nat_ftp nf_conntrack_ftp ip6table_raw ip6table_mangle 
> ip6table_nat xt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_LOG nf_log_syslog 
> ipt_REJECT nf_reject_ipv4 iptable_raw iptable_mangle xt_multiport xt_state 
> xt_limit xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c 
> ip6table_filter ip6_tables iptable_filter ip_tables x_tables ovpn_dco_v2(OE) 
> ip6_udp_tunnel udp_tunnel tcp_bbr nct6775 nct6775_core hwmon_vid br_netfilter 
> bridge stp llc nfnetlink_queue nfnetlink i915 ppdev intel_rapl_msr evdev 
> intel_rapl_common x86_pkg_temp_thermal intel_powerclamp drm_buddy coretemp 
> video rt2800usb wmi ghash_clmulni_intel drm_display_helper rt2x00usb 
> sha512_ssse3 sha512_generic rt2800lib rt2x00lib cec sha256_ssse3 sha1_ssse3 
> rc_core mac80211 aesni_intel ttm crypto_simd drm_kms_helper libarc4 cryptd 
> cfg80211 rapl intel_cstate drm intel_uncore rfkill parport_pc pcspkr
> May  7 08:10:12 cerberus kernel: [   76.203999]  serio_raw iTCO_wdt 
> intel_pmc_bxt iTCO_vendor_support parport watchdog at24 button ext4 crc16 
> mbcache jbd2 crc32c_generic sg sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif 
> crct10dif_generic ahci libahci libata crct10dif_pclmul crct10dif_common 
> crc32_pclmul crc32c_intel psmouse scsi_mod i2c_i801 i2c_smbus ehci_pci 
> ehci_hcd scsi_common lpc_ich usbcore igb i2c_algo_bit usb_common dca
> May  7 08:10:12 cerberus kernel: [   76.204039] CPU: 3 PID: 0 Comm: swapper/3 
> Tainted: G   OE  6.1.0-21-amd64 #1  Debian 6.1.90-1
> May  7 08:10:12 cerberus kernel: [   76.204044] Hardware name: Sophos UTM/To 
> be filled by O.E.M., BIOS 4.6.4 11/08/2011
> May  7 08:10:12 cerberus kernel: [   76.204046] RIP: 
> 0010:br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> May  7 08:10:12 cerberus kernel: [   76.204056] Code: df e8 4b b7 cd fa 66 83 
> ab b8 00 00 00 08 eb 94 be 04 00 00 00 48 89 df e8 34 b7 cd fa 66 83 ab b8 00 
> 00 00 04 e9 7a ff ff ff <0f> 0b e9 f0 fe ff ff 0f 0b e9 dd fe ff ff 48 89 ef 
> e8 41 67 d8 fa
> May  7 08:10:12 cerberus kernel: [   76.204059] RSP: 0018:bf5600144928 
> EFLAGS: 00010202
> May  7 08:10:12 cerberus kernel: [   76.204062] RAX: 0002 RBX: 
> 9ac2862ff300 RCX: 
> May  7 08:10:12 cerberus kernel: [   76.204065] RDX: bf5600144980 RSI: 
> 9ac2862ff300 RDI: 
> May  7 08:10:12 cerberus kernel: [   76.204067] RBP: 9ac2848a8100 R08: 
> 0001 R09: 9ac2872be980
> May  7 08:10:12 cerberus kernel: [   76.204070] R10: 9ac2872be000 R11: 
> 0002 R12: bf5600144980
> May  7 08:10:12 cerberus kernel: [   76.204072] R13:  R14: 
> 9ac282f4bac0 R15: 9ac2d027da00
> May  7 08:10:12 cerberus kernel: [   76.204074] FS:  () 
> GS:9ac5b018() knlGS:
> May  7 08:10:12 cerberus kernel: [   76.204077] CS:  0010 DS:  ES:  
> CR0: 80050033
> May  7 08:10:12 cerberus kernel: [   76.204080] CR2: 5618751eb018 CR3: 
> 2e610006 CR4: 000606e0
> May  7 08:10:12 cerberus kernel: [   76.204083] Call Trace:
> May  7 08:10:12 cerberus kernel: [   76.204087]  
> May  7 08:10:12 cerberus kernel: [   76.204090]  ? __warn+0x7d/0xc0
> May  7 08:10:12 cerberus kernel: [   76.204097]  ? br_nf_local_in+0x1a9/0x1d0 
> [br_netfilter]
> May  7 08:10:12 cerberus kernel: [   76.204105]  ? report_bug+0xe2/0x150
> May  7 08:10:12 cerberus kernel: [   76.204113]  

Bug#1070712: jinja2: CVE-2024-34064: Jinja vulnerable to HTML attribute injection when passing user input as keys to xmlattr filter

[Salvatore Bonaccorso]

Source: jinja2
Version: 3.1.3-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for jinja2.

CVE-2024-34064[0]:
| Jinja is an extensible templating engine. The `xmlattr` filter in
| affected versions of Jinja accepts keys containing non-attribute
| characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or
| `=`, as each would then be interpreted as starting a separate
| attribute. If an application accepts keys (as opposed to only
| values) as user input, and renders these in pages that other users
| see as well, an attacker could use this to inject other attributes
| and perform XSS. The fix for CVE-2024-22195 only addressed spaces
| but not other characters. Accepting keys as user input is now
| explicitly considered an unintended use case of the `xmlattr`
| filter, and code that does so without otherwise validating the input
| should be flagged as insecure, regardless of Jinja version.
| Accepting _values_ as user input continues to be safe. This
| vulnerability is fixed in 3.1.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-34064
https://www.cve.org/CVERecord?id=CVE-2024-34064
[1] https://github.com/pallets/jinja/security/advisories/GHSA-h75v-3vvj-5mfj
[2] 
https://github.com/pallets/jinja/commit/d655030770081e2dfe46f90e27620472a502289d

Please adjust the affected versions in the BTS as needed.

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#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Hi,

On Tue, May 07, 2024 at 03:30:58PM +, Kari Lempiäinen wrote:
> Hi,
> 
> New kernel 6.1.0-21 seems to be out. Could you verify if this bus is fixed in 
> it?
> 
> I found from 
> https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.90 that 
> there is a commit b3686200adba26dd1f8beee3d9c1b34563db1e65 is that a fix for 
> this?

I closed the bug in the changelog with it, with the testing case I had
at hand. But please verify if that is the case as well in your setup.

Can you then report back?

Regards,
Salvatore

Bug#1070665: python-aiohttp: CVE-2024-27306

[Salvatore Bonaccorso]

Source: python-aiohttp
Version: 3.9.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/aio-libs/aiohttp/pull/8319
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-aiohttp.

CVE-2024-27306[0]:
| aiohttp is an asynchronous HTTP client/server framework for asyncio
| and Python. A XSS vulnerability exists on index pages for static
| file handling. This vulnerability is fixed in 3.9.4. We have always
| recommended using a reverse proxy server (e.g. nginx) for serving
| static files. Users following the recommendation are unaffected.
| Other users can disable `show_index` if unable to upgrade.


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-27306
https://www.cve.org/CVERecord?id=CVE-2024-27306
[1] https://github.com/aio-libs/aiohttp/pull/8319
[2] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-7gpw-8wmc-pm8g
[3] 
https://github.com/aio-libs/aiohttp/commit/28335525d1eac015a7e7584137678cbb6ff19397

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#1070364: python-aiohttp: CVE-2024-30251

[Salvatore Bonaccorso]

Source: python-aiohttp
Version: 3.9.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-aiohttp.

CVE-2024-30251[0]:
| aiohttp is an asynchronous HTTP client/server framework for asyncio
| and Python. In affected versions an attacker can send a specially
| crafted POST (multipart/form-data) request. When the aiohttp server
| processes it, the server will enter an infinite loop and be unable
| to process any further requests. An attacker can stop the
| application from serving requests after sending a single request.
| This issue has been addressed in version 3.9.4. Users are advised to
| upgrade. Users unable to upgrade may manually apply a patch to their
| systems. Please see the linked GHSA for instructions.


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-30251
https://www.cve.org/CVERecord?id=CVE-2024-30251
[1] https://www.openwall.com/lists/oss-security/2024/05/02/4
[2] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-5m98-qgg9-wh84

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070362: libcoap3: CVE-2024-31031

[Salvatore Bonaccorso]

Source: libcoap3
Version: 4.3.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/obgm/libcoap/issues/1351
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libcoap3.

CVE-2024-31031[0]:
| An issue in `coap_pdu.c` in libcoap 4.3.4 allows attackers to cause
| undefined behavior via a sequence of messages leading to unsigned
| integer overflow.


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-31031
https://www.cve.org/CVERecord?id=CVE-2024-31031
[1] https://github.com/obgm/libcoap/issues/1351
[2] 
https://github.com/obgm/libcoap/commit/214665ac4b44b1b6a7e38d4d6907ee835a174928

Regards,
Salvatore

Bug#1070330: [Pkg-libvirt-maintainers] Bug#1070330: libvirt: CVE-2024-4418: stack use-after-free in virNetClientIOEventLoop()

[Salvatore Bonaccorso]

Hi Guido,

On Fri, May 03, 2024 at 09:47:30PM +0200, Guido Günther wrote:
> control: -1 +pending
> 
> Hi,
> On Fri, May 03, 2024 at 09:10:23PM +0200, Salvatore Bonaccorso wrote:
> > Source: libvirt
> > Version: 10.2.0-1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for libvirt.
> > 
> > CVE-2024-4418[0]:
> > | stack use-after-free in virNetClientIOEventLoop()
> > 
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> See https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/220

Ah, very nice. Thanks!

Regards,
Salvatore

Bug#1070330: libvirt: CVE-2024-4418: stack use-after-free in virNetClientIOEventLoop()

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for libvirt.

CVE-2024-4418[0]:
| stack use-after-free in virNetClientIOEventLoop()


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-4418
https://www.cve.org/CVERecord?id=CVE-2024-4418
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2278616
[2] 
https://gitlab.com/libvirt/libvirt/-/commit/8074d64dc2eca846d6a61efe1a9b7428a0ce1dd1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1069681: less does not escape special characters when outputting the filename

[Salvatore Bonaccorso]

Hi Milan,

On Thu, May 02, 2024 at 12:54:10PM -0400, Milan Kupcevic wrote:
> Hi Salvatore,
> 
> On 5/2/24 10:45, Salvatore Bonaccorso wrote:
> [...]
> > 
> > I did ponder about it and trying to add this fix as well for the
> > upcoming less DSA, but it won't go apply for the older releases and
> > the issue is compared minor enough.
> > 
> > I think I will go ahead with the two CVE fixes only.
> > 
> Take a look at the attached patch. It applies and fixes the bookworm and
> bullseye versions. It seems the buster version is not vulnerable to this
> particular issue.

Ah right that's the same you applied in unstable AFAICS and
backported. I will have a look, so that could make it as well into the
DSA released version.

Thanks a lot!

Regards,
Salvatore

Bug#1069681: less does not escape special characters when outputting the filename

[Salvatore Bonaccorso]

Hi Milan,

On Tue, Apr 23, 2024 at 09:08:55AM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Apr 22, 2024 at 12:25:45PM -0400, Milan Kupcevic wrote:
> > forwarded 1069681 https://github.com/gwsw/less/issues/503
> > thanks
> 
> Thanks. For now I will hold-back the prepared security update to see
> if there is something else which needs to be done here.

I did ponder about it and trying to add this fix as well for the
upcoming less DSA, but it won't go apply for the older releases and
the issue is compared minor enough.

I think I will go ahead with the two CVE fixes only.

Let me know if you think otherwise.

Regards,
Salvatore

Bug#1069895: [debian-mysql] Bug#1069895: mariadb-server: InnoDB to hang on systems with very intensive write loads when running out of I/O slots. This problem is fixed with MariaDB Server 10.11.7. Can

[Salvatore Bonaccorso]

Hi,

On Fri, Apr 26, 2024 at 02:27:12PM -0700, Otto Kekäläinen wrote:
> We can put 10.11.7 in Stable until it yas been accepted in Testing first.
> It is on the way though.

I guess it won't migrate very soon yet to testing (due to tim64
transition?). In such case it would still be good to ask SRM for
accepting it for the next point release (given it is fixed in unstable
and this version *is* aimed to go to trixie).

Regards,
Salvatore

Bug#960062: closed by gregor herrmann (Re: Bug#960062:)

[Salvatore Bonaccorso]

Hi 

On Wed, Feb 21, 2024 at 07:57:06PM +, Debian Bug Tracking System wrote:
[...]
> Version: 1.949-1
> 
> On Tue, 28 Nov 2023 11:43:27 +0100, Miriam Espana Acebal wrote:
> 
> > I'm working on this package on Ubuntu, to promote it from universe to main.
> > I saw this bug, and it could be a blocker for that process. Reading the
> > changes files,
> > the following entry seems to be related (per the comments on
> > upstream's issue [1] too):
> > 
> >  1.947 2020-05-09 14:30:06-04:00 America/New_York (TRIAL RELEASE)
> > - add $Email::MIME::MAX_DEPTH and refuse to parse deeper than that
> > many
> >   parts; current default: 10
> > 
> > Do you know, as maintainers, if this bug is fixed with that?  One of the
> > reviewers already asked upstream [1] to see if we can get a confirmation
> > from there.
> 
> This has been answered in the upstream ticket now:
> https://github.com/msimerson/mail-dmarc/issues/216#issuecomment-1945033737
> 
> Hence closing the bug (at the first version after 1.947 which was
> uploaded to the Debian archive.)

As per
https://github.com/rjbs/Email-MIME/issues/66#issuecomment-2024085120
I'm reopening this issue. Let's consider it only as fixed once the
changes provided by rjbs are merged as well? Is that okay for you
Gregor?

Regards,
Salvatore

Bug#1069690: bookworm-pu: package libkf5ksieve/4:22.12.3-1+deb12u1

[Salvatore Bonaccorso]

Hi Patrick,

On Mon, Apr 22, 2024 at 09:36:54PM +0200, Patrick Franz wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> X-Debbugs-Cc: delta...@debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> There is a bug in libkf5sieve where the password instead of the
> username is sent when using managesieve and could therefore be
> logged on a server as the login will fail.
> 
> [ Impact ]
> Potentially sensitive passwords are logged on a server.
> 
> [ Tests ]
> Affected user has successfully tested the patched version.
> 
> [ Risks ]
> The patch is trivial (1 line is changed) and it's quite obvious
> that it was a bug in the first place.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> 1-line patch to fix the bug.

> diffstat for libkf5ksieve-22.12.3 libkf5ksieve-22.12.3

As it is not yet uploaded for bookworm, you might add as well the CVE
id reference in the changelog: CVE-2023-52723 .

p.s.: I think you can take advantage of the improved workflow for this
specific one, if you are sure the package will be accepted as it is
from SRM, you can with the proposed update bug filling, along as well
already do the upload.

(but note, just commenting this with no authrotiy speaking, as not
part of the release team)

Regards,
Salvatore

Bug#1070207: dcmtk: CVE-2024-28130

[Salvatore Bonaccorso]

Source: dcmtk
Version: 3.6.7-13
Severity: important
Tags: security upstream
Forwarded: https://support.dcmtk.org/redmine/issues/1120
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.6.7-9
Control: found -1 3.6.7-8

Hi,

The following vulnerability was published for dcmtk.

CVE-2024-28130[0]:
| An incorrect type conversion vulnerability exists in the
| DVPSSoftcopyVOI_PList::createFromImage functionality of OFFIS DCMTK
| 3.6.8. A specially crafted malformed file can lead to arbitrary code
| execution. An attacker can provide a malicious file to trigger this
| 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-28130
https://www.cve.org/CVERecord?id=CVE-2024-28130
[1] https://support.dcmtk.org/redmine/issues/1120
[2] https://talosintelligence.com/vulnerability_reports/TALOS-2024-1957
[3] 
https://github.com/DCMTK/dcmtk/commit/601b227eecaab33a3a3a11dc256d84b1a62f63af

https://github.com/DCMTK/dcmtk/commit/7d54f8efec995e5601d089fa17b0625c2b41af23

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070148: sqlparse: CVE-2024-4340: sqlparse parsing heavily nested list leads to Denial of Service

[Salvatore Bonaccorso]

Source: sqlparse
Version: 0.4.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sqlparse.

CVE-2024-4340[0]:
| Passing a heavily nested list to sqlparse.parse() leads to a Denial
| of Service due to RecursionError.


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-4340
https://www.cve.org/CVERecord?id=CVE-2024-4340
[1] https://github.com/advisories/GHSA-2m57-hf25-phgg
[2] 
https://github.com/andialbrecht/sqlparse/commit/b4a39d9850969b4e1d6940d32094ee0b42a2cf03

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1065688: python-jwcrypto: CVE-2024-28102

[Salvatore Bonaccorso]

Hi Steve,

On Tue, Apr 30, 2024 at 05:19:22PM +0100, Steve McIntyre wrote:
> Hi!
> 
> On Fri, Mar 08, 2024 at 10:42:40PM +0100, Salvatore Bonaccorso wrote:
> >Source: python-jwcrypto
> >Version: 1.5.4-1
> >Severity: important
> >Tags: security upstream
> >X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> >
> >
> >Hi,
> >
> >The following vulnerability was published for python-jwcrypto.
> >
> >CVE-2024-28102[0]:
> >| JWCrypto implements JWK, JWS, and JWE specifications using python-
> >| cryptography. Prior to version 1.5.6, an attacker can cause a denial
> >| of service attack by passing in a malicious JWE Token with a high
> >| compression ratio. When the server processes this token, it will
> >| consume a lot of memory and processing time. Version 1.5.6 fixes
> >| this vulnerability by limiting the maximum token length.
> 
> We wanted this fixed in Pexip, so I've taken a look at this bug.
> 
> The upstream bugfix just needs a small rework so it applies cleanly to
> the version in bookworm. Here's a debdiff for that that in case it's
> useful.

The issue does not warrant a DSA, but would be great if fixed in
bookworm if you have done already the work, via a upcoming point
release.

Can you propose the update in stable (unless the maintainers want to
do it on their own)?

Regards,
Salvatore

Bug#1070140: tpm2-tss: CVE-2024-29040

[Salvatore Bonaccorso]

Source: tpm2-tss
Version: 4.0.1-7
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for tpm2-tss.

CVE-2024-29040[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-29040
https://www.cve.org/CVERecord?id=CVE-2024-29040
[1] 
https://github.com/tpm2-software/tpm2-tss/commit/710cd0b6adf3a063f34a8e92da46df7a107d9a99

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070139: tpm2-tools: CVE-2024-29038 CVE-2024-29039

[Salvatore Bonaccorso]

Source: tpm2-tools
Version: 5.6-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for tpm2-tools.

CVE-2024-29038[0] and CVE-2024-29039[1].

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-29038
https://www.cve.org/CVERecord?id=CVE-2024-29038

https://github.com/tpm2-software/tpm2-tools/commit/66d922d6547b7b4fe4f274fb2ec10b376e0e259c
[1] https://security-tracker.debian.org/tracker/CVE-2024-29039
https://www.cve.org/CVERecord?id=CVE-2024-29039

https://github.com/tpm2-software/tpm2-tools/commit/98599df9392a346216c5a059b8d35271286100bb

Regards,
Salvatore

Bug#1070083: linux: Do we still need sched-autogroup-disabled.patch in 2024?

[Salvatore Bonaccorso]

Hi,

On Tue, Apr 30, 2024 at 02:10:20AM +0500, Alex Volkov wrote:
> Source: linux
> Severity: normal
> 
> Dear Maintainer,
> 
> I can't see why something which can be done with a kernel boot parameter or a
> sysctl variable
> needs to be forced in the source since 2011. Also, the very existence of this
> new default is non-transparent for anyone relying on official kernel
> documentation. Is it even mentioned in any README or something? Because I
> couldn't find anything.

It was set as such a long time ago when we enabled the option:

https://salsa.debian.org/kernel-team/linux/-/commit/25e71bd23902b424ec9457244db24faad8b4359f

I suspect the idea was to make it possible for users to use this new
feature, but only as a opt-in, while it was still very fresh.

Maybe Ben remembers.

But I guess we could drop the Debian specific patch.

Regards,
Salvatore

Bug#1064808: Accepted node-sanitize-html 2.13.0+~2.11.0-1 (source) into unstable

[Salvatore Bonaccorso]

Source: node-sanitize-html
Source-Version: 2.13.0+~2.11.0-1

On Sun, Apr 28, 2024 at 02:40:18PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 28 Apr 2024 17:48:12 +0400
> Source: node-sanitize-html
> Built-For-Profiles: nocheck
> Architecture: source
> Version: 2.13.0+~2.11.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Javascript Maintainers 
> 
> Changed-By: Yadd 
> Changes:
>  node-sanitize-html (2.13.0+~2.11.0-1) unstable; urgency=medium
>  .
>* Team upload
>* Update lintian override info format in d/source/lintian-overrides
>  on line 4-5
>* Declare compliance with policy 4.7.0
>* New upstream release (Closes: CVE-2024-21501)
>* Unfuzz patches
> Checksums-Sha1: 
>  fcf4b0215aafdcede7959494b0da422d54e1cfb5 2729 
> node-sanitize-html_2.13.0+~2.11.0-1.dsc
>  582d8c72215c0228e3af2be136e40e0b531addf2 2828 
> node-sanitize-html_2.13.0+~2.11.0.orig-types-sanitize-html.tar.gz
>  ae75ec4d6145dabd57328e9ab0cbddcf5a59830b 45951 
> node-sanitize-html_2.13.0+~2.11.0.orig.tar.gz
>  e5ba4b5c3f17715597b63a7566a44b31e268cdd2 3736 
> node-sanitize-html_2.13.0+~2.11.0-1.debian.tar.xz
> Checksums-Sha256: 
>  248588aadd03932b4a6f8c7545127894e5058379706d361fc77d0e7786860c49 2729 
> node-sanitize-html_2.13.0+~2.11.0-1.dsc
>  c0f4ed19e9f1dd0a53fbe204e803e73008d760a549116cd98f3ec67a7d434ad7 2828 
> node-sanitize-html_2.13.0+~2.11.0.orig-types-sanitize-html.tar.gz
>  f50aec59bb5de24115864a852bccc2bd7033b3459f4087910f2173f4e9bf3e54 45951 
> node-sanitize-html_2.13.0+~2.11.0.orig.tar.gz
>  9790307661157f4a9c2b24d76a9c646f0c6b64e6cc8396cfd1234a0226176f57 3736 
> node-sanitize-html_2.13.0+~2.11.0-1.debian.tar.xz
> Files: 
>  357330bee53c034e00803a83216f1062 2729 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0-1.dsc
>  11a9538eda02816f35805a34e88eb09d 2828 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0.orig-types-sanitize-html.tar.gz
>  d8cb51cb238cc377e69d1a651be83435 45951 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0.orig.tar.gz
>  7486b0a164aa88b192c0300022070e7f 3736 javascript optional 
> node-sanitize-html_2.13.0+~2.11.0-1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYuVCcACgkQ9tdMp8mZ
> 7um/qQ/+OjkDvMLLDu2JQLHsZh0OvuKFfjUgFdnhXdRZeS2kg1IVZd9xVUu864Ri
> quHE88QVy+4Ak5TxChEhYZxl8GAXXCpoe5oirHRIJlhw1FS4B7Uf2i50ccTm9OfE
> K22lr6VBgxhP8XzkDE4yLVfUyXS2NjbVW7olTYqL6GFzAllA2Xu6EFC+u25C3ruH
> drCg/MO33NZRal68qBUSNEenDmT9IEpfHUNOLxrukSSx1512DlcCJvw8EqAPMCwR
> wsJwvvJb6ryh7BouE6qsELG+DnwOHARx00I3iir48mWjAjNV46haj1y5Rc3+TIQm
> vC2Dsr7aWdtucAlyRWxl4X+E+15WUkOollbG3y5cLExHFUpXqu5SbSYqBqDepdYm
> xf1Oc/nSAv5/1mtDgT6nl72lr5OeGEGc+eDN9yEyy7cxwHMttI7IM/iZ/nd6l9Ie
> l1e1ySCJqO/D2Vcg7HOWWq8v8hj/ZVZnllaT3+d9Q22SGtwNuQIJfyq8GOHuxjli
> 8SnBemEUB4xEsbJpNz+d5woh3Uvf/0Z4Pk9UK1F4Rz0VeDGuhkHuyVLFxcPm20el
> 7E1WJ63zN4xg8B0zCWfJ3TJLRgWhJnzPF0IkoQiovXU6ha368TmAouuQRa2Pzy4Z
> D/jNaOxb1OqPdwtjfZ40fNu+9VaLjsFiIRRs2Eueaa/nMuy5r2k=
> =+7g+
> -END PGP SIGNATURE-
> 

Bug#1063535: Accepted node-ip 2.0.1+~1.1.3-1 (source) into unstable

[Salvatore Bonaccorso]

Source: node-ip
Source-Version: 2.0.1+~1.1.3-1

On Sun, Apr 28, 2024 at 02:40:08PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 28 Apr 2024 17:44:01 +0400
> Source: node-ip
> Architecture: source
> Version: 2.0.1+~1.1.3-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Javascript Maintainers 
> 
> Changed-By: Yadd 
> Changes:
>  node-ip (2.0.1+~1.1.3-1) unstable; urgency=medium
>  .
>* Team upload
>* Declare compliance with policy 4.7.0
>* New upstream version (Closes: CVE-2023-42282)
>* Unfuzz patches
> Checksums-Sha1: 
>  c951a3237457516c4932de97e6b040eb590e1945 2302 node-ip_2.0.1+~1.1.3-1.dsc
>  5d8634b3514a51768adda5e17c91a11cdb2e5247 2392 
> node-ip_2.0.1+~1.1.3.orig-types-ip.tar.gz
>  497fb529449bf1db7734ffb9f26ec18db0553267 35824 
> node-ip_2.0.1+~1.1.3.orig.tar.gz
>  18ada04f9e27e8b73408cc5857b9105c72752094 3536 
> node-ip_2.0.1+~1.1.3-1.debian.tar.xz
> Checksums-Sha256: 
>  155a2eff41959eb5ac609794197da71c85fa2563cc2d2cc8a2441f8b33a056d7 2302 
> node-ip_2.0.1+~1.1.3-1.dsc
>  5dae9ca606ec5b95e21c78609c8c9ceef7808b36592258766a40a9aeade753b5 2392 
> node-ip_2.0.1+~1.1.3.orig-types-ip.tar.gz
>  ee8b0634c671b58d135a07fcfb70b41d7d9c9e457db6ade06982f7c38df526d3 35824 
> node-ip_2.0.1+~1.1.3.orig.tar.gz
>  d54aea7b8f3bf090547c1792e659eec9568b9eae4d18a4c7a42f83e5275d2540 3536 
> node-ip_2.0.1+~1.1.3-1.debian.tar.xz
> Files: 
>  9fc45e1089a79918b594c09a71f33198 2302 javascript optional 
> node-ip_2.0.1+~1.1.3-1.dsc
>  d937a8472e46d87f5a6928bc92599ff9 2392 javascript optional 
> node-ip_2.0.1+~1.1.3.orig-types-ip.tar.gz
>  f4f085a822f61608dac1de6bdf1377fb 35824 javascript optional 
> node-ip_2.0.1+~1.1.3.orig.tar.gz
>  a9a1508cc10542a3d1751143ed098ec2 3536 javascript optional 
> node-ip_2.0.1+~1.1.3-1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYuUssACgkQ9tdMp8mZ
> 7ukK1RAAnntmtKJD/wR6EU/ELjRRQEbQOYf+WQ0Uek09Sv5fKlC/tpbQT8uHFJAc
> ibBb85CIo0gzCd4+k1BZzXQwCt1eoaqTfNITjHIjyFIEu+KKQP4HVCkxxqRz1MNE
> 9WHWHEyH+Qfy60zVVwPgaDz7L16J4Pf//KwdROJMLLPDT4sa9VZjyp/nDsGTtZTp
> 6oBpWrvpVmfEVKl4ovx6jSPzGSd7s/MTcP9HqIy+v39fyMxCdyMHigf4T+hZNgi1
> 0sa6kaXjMicDEdyCfdz8ZMGagO0hyGadJnxguIm9yz0svz5ykk2JnDGKEWJ76h0H
> smDXP1BW9SSpPfPyERDev2V4jjGdgy2XsJOAQ3H6RzQCvAD4lAK95Ca6shoPU6/y
> ZNmVwbZaueRJfSYZNbOVBSJEup2UenGkb34Wge00gd7IlJFo/Ts6b0TOl1BApGuI
> N2IbB00Q7h7Dg+4YdOyVROi74sXXzn8V0Ehv1vdimr8+qr1X+a+/lbYBBqoPiUSS
> S0xcgzJ8UmJDVp3C6CjSJifANi0SIrdT1IDqSmNxATyXAszQ+7WTbzJDUKclxASa
> g7+Vd/piIaO4nd3pv2SsyFdoW/pe+o9Wkqb9HAnQ9UIpaJrJVbGLcGiRN1xt1Dtj
> naAhta0leuGeHvgJqr9NtFQEypSuPlMZD7Agm50dS0k3Jag9mmI=
> =Bygl
> -END PGP SIGNATURE-
> 

Bug#1064933: Accepted node-es5-ext 0.10.64+dfsg1+~1.1.0-1 (source) into unstable

[Salvatore Bonaccorso]

Source: node-es5-ext
Source-Version: 0.10.64+dfsg1+~1.1.0-1

On Sun, Apr 28, 2024 at 02:39:58PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 28 Apr 2024 17:42:38 +0400
> Source: node-es5-ext
> Architecture: source
> Version: 0.10.64+dfsg1+~1.1.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Javascript Maintainers 
> 
> Changed-By: Yadd 
> Changes:
>  node-es5-ext (0.10.64+dfsg1+~1.1.0-1) unstable; urgency=medium
>  .
>* Team upload
>* Declare compliance with policy 4.7.0
>* New upstream version (CLoses: CVE-2024-27088)
> Checksums-Sha1: 
>  00ac9a9cc333a9591819f29f9dc201a44b86ed39 2502 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.dsc
>  47adcb21fae6891d7ee7361925cd9271b17014d8 4000 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig-next-tick.tar.xz
>  a14349957458b4c3a550ddc89a8eb46d3ac55060 98820 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig.tar.xz
>  b66861c5b13af54d9f17fb848bf2ef97bc05f010 4368 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.debian.tar.xz
> Checksums-Sha256: 
>  56f461199b70efb68d0a7b6fc1933dccd192682112334c404fd0af77b4ca729b 2502 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.dsc
>  4b88466e757b6cddefed1275407b4aced0f9379c1caec88fc0dbd737f218ea67 4000 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig-next-tick.tar.xz
>  73eefa5ace80aa1ca02c4e8d941c892c92d511ecc90186313bcef739f0e960a5 98820 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig.tar.xz
>  f70ca85871aa3c5c8a6eaf8d4bf1d5789fdd46e08511d3230bf87057b359a306 4368 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.debian.tar.xz
> Files: 
>  96882f12a6df1d1e5cbd19205a4b2c85 2502 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.dsc
>  503a8a5ea72aeab3a8f9af621752bb1e 4000 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig-next-tick.tar.xz
>  ecbd763c6d41f64d0a4b762d3e5fb921 98820 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0.orig.tar.xz
>  a12714528ad453fe2de55bcf011c2b15 4368 javascript optional 
> node-es5-ext_0.10.64+dfsg1+~1.1.0-1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYuUrgACgkQ9tdMp8mZ
> 7ulscA//fdH9BrZjJRz5yrUIEJBIQPGwmjbLgv0pYfOBXCcchb6jlt2eCGrZhocQ
> sUju3+bf3XwsOhPiESJ8crt50VhQrF4ymGFlYZKxpAURFcQYFJ0s2+BAybwo6o60
> JOa1+rvcU/qFUm+yvECRFgH4rO67uWkIYfdxPYRiW5Q9+Elu/BqBqVW778sxzXai
> n/auHL6v0yWh002ATorJWN0BqcVDTIvc+O9dX8WjWquNb0xylTnCv8xIMrskaIOj
> g2yu7Wpd2n7d4FsF7RNcauUHRb+tUl1b3uDrfLjf/twH6BEfNa6u0ASIdrPNNtw5
> z7Nn2JlbdQuoSjPfQXNHJ6u9ihRfEuHKfV2CLorxt/yS5QrrpxyaEIPRE1KbhO/L
> +SAlM5PfLg2boMxSoWXjTL3emamsFa46P6BdzpEQQl/6uhKYjTCQucP8NAAgoPUx
> G4QKE0kkgBF08dxn4e7WKmkkMfP1xeJ3hFVC9qD8BcCmKij0kCU9SAMmm9rEMsKD
> MEJnho+7kqO+Y3owwjrMFaKkLR0dXNiox81CF/gtVwK77Mka/sX95sSrS4A2mecb
> /jCMmc4JRJ8tuLcrnb3AMC/EAkPCnd36T3OEez3gWD/qYOR/afirNN2h5EhSrNcH
> qMRuG6IHhBvRLeUd9L1R2TA7KdPGr431cOVQr/ojsRnA2I5gTaM=
> =UP4E
> -END PGP SIGNATURE-

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

Bug#1069966: ruby3.1: CVE-2024-27280: Buffer overread vulnerability in StringIO

[Salvatore Bonaccorso]

Source: ruby3.1
Version: 3.1.2-8
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.1.2-7

Hi,

The following vulnerability was published for ruby3.1.

CVE-2024-27280[0]:
| Buffer overread vulnerability in StringIO


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-27280
https://www.cve.org/CVERecord?id=CVE-2024-27280
[1] https://www.ruby-lang.org/en/news/2024/03/21/buffer-overread-cve-2024-27280/

Regards,
Salvatore

Bug#1069752: freerdp3: CVE-2024-32658 CVE-2024-32659 CVE-2024-32660 CVE-2024-32661

[Salvatore Bonaccorso]

Source: freerdp3
Version: 3.5.0+dfsg1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for freerdp3.

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

Regards,
Salvatore

Bug#1069728: freerdp2: CVE-2024-32039 CVE-2024-32040 CVE-2024-32041 CVE-2024-32458 CVE-2024-32459 CVE-2024-32460

[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-32039[0]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients using a version of FreeRDP prior to 3.5.0 or
| 2.11.6 are vulnerable to integer overflow and out-of-bounds write.
| Versions 3.5.0 and 2.11.6 patch the issue. As a workaround, do not
| use `/gfx` options (e.g. deactivate with `/bpp:32` or `/rfx` as it
| is on by default).


CVE-2024-32040[1]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients that use a version of FreeRDP prior to 3.5.0
| or 2.11.6 and have connections to servers using the `NSC` codec are
| vulnerable to integer underflow. Versions 3.5.0 and 2.11.6 patch the
| issue. As a workaround, do not use the NSC codec (e.g. use `-nsc`).


CVE-2024-32041[2]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients that use a version of FreeRDP prior to 3.5.0
| or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and
| 2.11.6 patch the issue. As a workaround, deactivate `/gfx` (on by
| default, set `/bpp` or `/rfx` options instead.


CVE-2024-32458[3]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients that use a version of FreeRDP prior to 3.5.0
| or 2.11.6 are vulnerable to out-of-bounds read. Versions 3.5.0 and
| 2.11.6 patch the issue. As a workaround, use `/gfx` or `/rfx` modes
| (on by default, require server side support).


CVE-2024-32459[4]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based clients and servers that use a version of FreeRDP
| prior to 3.5.0 or 2.11.6 are vulnerable to out-of-bounds read.
| Versions 3.5.0 and 2.11.6 patch the issue. No known workarounds are
| available.


CVE-2024-32460[5]:
| FreeRDP is a free implementation of the Remote Desktop Protocol.
| FreeRDP based based clients using `/bpp:32` legacy `GDI` drawing
| path with a version of FreeRDP prior to 3.5.0 or 2.11.6 are
| vulnerable to out-of-bounds read. Versions 3.5.0 and 2.11.6 patch
| the issue. As a workaround, use modern drawing paths (e.g. `/rfx` or
| `/gfx` options). The workaround requires server side support.


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-32039
https://www.cve.org/CVERecord?id=CVE-2024-32039
[1] https://security-tracker.debian.org/tracker/CVE-2024-32040
https://www.cve.org/CVERecord?id=CVE-2024-32040
[2] https://security-tracker.debian.org/tracker/CVE-2024-32041
https://www.cve.org/CVERecord?id=CVE-2024-32041
[3] https://security-tracker.debian.org/tracker/CVE-2024-32458
https://www.cve.org/CVERecord?id=CVE-2024-32458
[4] https://security-tracker.debian.org/tracker/CVE-2024-32459
https://www.cve.org/CVERecord?id=CVE-2024-32459
[5] https://security-tracker.debian.org/tracker/CVE-2024-32460
https://www.cve.org/CVERecord?id=CVE-2024-32460
[6] https://www.freerdp.com/2024/04/17/2_11_6-release

Regards,
Salvatore

Bug#1069681: less does not escape special characters when outputting the filename

[Salvatore Bonaccorso]

Hi,

On Mon, Apr 22, 2024 at 12:25:45PM -0400, Milan Kupcevic wrote:
> forwarded 1069681 https://github.com/gwsw/less/issues/503
> thanks

Thanks. For now I will hold-back the prepared security update to see
if there is something else which needs to be done here.

Regards,
Salvatore

Bug#1064293: less: CVE-2022-48624

[Salvatore Bonaccorso]

Hi,

On Sat, Apr 20, 2024 at 07:54:13AM -0400, P. J. McDermott wrote:
> On 2024-04-19 at 15:55, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > FWIW, I'm actually preparing a security update for the two CVEs and
> > for bookworm I was first planning to do a 590-2.1 reaching unstable,
> > and so then 590-2.1~deb12u1 for bookworm.
> > 
> > But if you want to override it with a NMU and proposing to salvage the
> > package this is equally fine.
> 
> Your DELAYED/2 NMU is probably the fastest and best way to get these
> CVEs fixed in unstable and bookworm, so that's fine, thanks.  Any plans
> for 551-2 in bullseye?  The two patches in your NMU apply cleanly there.

Yes, both bookworm-security and bullseye-security updates are already
prepared and uploaded to security-master. I will wait for some
exposure of less in unstable with the two fixes before releasing the
DSA.

I have not pushed the changes yet to the repository (will be done
after the DSA release).

I cannot comment on the salvaging of the package directly, as Milan has
responded to the bug and even acked the NMU. So I assume he is active
and you need to discuss with him on co-maintainership for less. But as
I read the discussion is already happening. So stopping here to
comment.

Regards,
Salvatore

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

[Salvatore Bonaccorso]

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.

Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Jeremy,

On Fri, Apr 19, 2024 at 05:37:41PM +0200, Jeremy Lainé wrote:
> Package: src:linux
> Version: 6.1.85-1
> Severity: important
> X-Debbugs-Cc: jeremy.la...@m4x.org
> 
> Dear Maintainer,
> 
> After upgrading from linux-image-6.1.0-18-amd64 to
> linux-image-6.1.0-20-amd64, bluetooth no longer works and a kernel BUG is
> visible in dmesg hinting at a memory safety issue.
> 
> It is not necessary to attempt to connect to any specific bluetooth
> device to trigger the problem, the problem arises as soon as the system
> boots.
> 
> I cannot reproduce the problem when booting back into the previous kernel
> image.

Would it be possible to do some experiments/debugging:

- Can you reproduce the issue with 6.1.85 upstream itself?

- If so can you try the current 6.1.87 (as of time of writing), does
  the issue reproduce there?

- If it's still happening, can you try to bisect the changes between
  6.1.76 and 6.1.85 to identify the culprit?

Regards,
Salvatore

Bug#1064293: less: diff for NMU version 590-2.1

[Salvatore Bonaccorso]

Control: tags 1064293 + patch
Control: tags 1064293 + pending
Control: tags 1068938 + patch
Control: tags 1068938 + pending


Dear maintainer,

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

As well pushed in a separte branch on salsa, which can be merged if
accepted to unstable:

https://salsa.debian.org/debian/less/-/tree/sid-2024-security-fixes?ref_type=heads

Regards.
Salvatore
diff -Nru less-590/debian/changelog less-590/debian/changelog
--- less-590/debian/changelog	2023-03-12 17:18:18.0 +0100
+++ less-590/debian/changelog	2024-04-19 15:09:49.0 +0200
@@ -1,3 +1,13 @@
+less (590-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Shell-quote filenames when invoking LESSCLOSE (CVE-2022-48624)
+(Closes: #1064293)
+  * Fix bug when viewing a file whose name contains a newline (CVE-2024-32487)
+(Closes: #1068938)
+
+ -- Salvatore Bonaccorso   Fri, 19 Apr 2024 15:09:49 +0200
+
 less (590-2) sid; urgency=medium
 
   * d/control: set standards version to 4.6.2
diff -Nru less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch
--- less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch	1970-01-01 01:00:00.0 +0100
+++ less-590/debian/patches/Fix-bug-when-viewing-a-file-whose-name-contains-a-ne.patch	2024-04-19 15:09:49.0 +0200
@@ -0,0 +1,67 @@
+From: Mark Nudelman 
+Date: Thu, 11 Apr 2024 17:49:48 -0700
+Subject: Fix bug when viewing a file whose name contains a newline.
+Origin: https://github.com/gwsw/less/commit/007521ac3c95bc76e3d59c6dbfe75d06c8075c33
+Bug-Debian: https://bugs.debian.org/1068938
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-32487
+
+---
+ filename.c | 31 +--
+ 1 file changed, 25 insertions(+), 6 deletions(-)
+
+--- a/filename.c
 b/filename.c
+@@ -136,6 +136,15 @@ metachar(c)
+ }
+ 
+ /*
++ * Must use quotes rather than escape char for this metachar?
++ */
++static int must_quote(char c)
++{
++	/* {{ Maybe the set of must_quote chars should be configurable? }} */
++	return (c == '\n'); 
++}
++
++/*
+  * Insert a backslash before each metacharacter in a string.
+  */
+ 	public char *
+@@ -168,6 +177,9 @@ shell_quote(s)
+  * doesn't support escape chars.  Use quotes.
+  */
+ use_quotes = 1;
++			} else if (must_quote(*p))
++			{
++len += 3; /* open quote + char + close quote */
+ 			} else
+ 			{
+ /*
+@@ -197,15 +209,22 @@ shell_quote(s)
+ 	{
+ 		while (*s != '\0')
+ 		{
+-			if (metachar(*s))
++			if (!metachar(*s))
+ 			{
+-/*
+- * Add the escape char.
+- */
++*p++ = *s++;
++			} else if (must_quote(*s))
++			{
++/* Surround the char with quotes. */
++*p++ = openquote;
++*p++ = *s++;
++*p++ = closequote;
++			} else
++			{
++/* Insert an escape char before the char. */
+ strcpy(p, esc);
+ p += esclen;
++*p++ = *s++;
+ 			}
+-			*p++ = *s++;
+ 		}
+ 		*p = '\0';
+ 	}
diff -Nru less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch
--- less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch	1970-01-01 01:00:00.0 +0100
+++ less-590/debian/patches/Shell-quote-filenames-when-invoking-LESSCLOSE.patch	2024-04-19 15:09:49.0 +0200
@@ -0,0 +1,43 @@
+From: Mark Nudelman 
+Date: Sat, 25 Jun 2022 11:54:43 -0700
+Subject: Shell-quote filenames when invoking LESSCLOSE.
+Origin: https://github.com/gwsw/less/commit/c6ac6de49698be84d264a0c4c0c40bb870b10144
+Bug-Debian: https://bugs.debian.org/1064293
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-48624
+
+---
+ filename.c | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/filename.c b/filename.c
+index 5824e385dce4..dff20c08d81c 100644
+--- a/filename.c
 b/filename.c
+@@ -972,6 +972,8 @@ close_altfile(altfilename, filename)
+ {
+ #if HAVE_POPEN
+ 	char *lessclose;
++	char *qfilename;
++	char *qaltfilename;
+ 	FILE *fd;
+ 	char *cmd;
+ 	int len;
+@@ -986,9 +988,13 @@ close_altfile(altfilename, filename)
+ 		error("LESSCLOSE ignored; must contain no more than 2 %%s", NULL_PARG);
+ 		return;
+ 	}
+-	len = (int) (strlen(lessclose) + strlen(filename) + strlen(altfilename) + 2);
++	qfilename = shell_quote(filename);
++	qaltfilename = shell_quote(altfilename);
++	len = (int) (strlen(lessclose) + strlen(qfilename) + strlen(qaltfilename) + 2);
+ 	cmd = (char *) ecalloc(len, sizeof(char));
+-	SNPRINTF2(cmd, len, lessclose, filename, altfilename);
++	SNPRINTF2(cmd, len, lessclose, qfilename, qaltfilename);
++	free(qaltfilename);
++	free(qfilename);
+ 	fd = shellcmd(cmd);
+ 	free(cmd);
+ 	if (fd != NULL)
+-- 
+2.43.0
+
diff -Nru less-590/debian/patches/serie

Bug#1064293: less: CVE-2022-48624

[Salvatore Bonaccorso]

Hi,

FWIW, I'm actually preparing a security update for the two CVEs and
for bookworm I was first planning to do a 590-2.1 reaching unstable,
and so then 590-2.1~deb12u1 for bookworm.

But if you want to override it with a NMU and proposing to salvage the
package this is equally fine.

Regards,
Salvatore

Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Hi Kari,

On Thu, Apr 18, 2024 at 05:31:33AM +, Kari Lempiäinen wrote:
> Hi,
> 
> I think I spoke too soon. I removed  'noserverino' options from all
> my cifs mounts yesterday and u/remounted them. From last night
> syslog I can still find the "directory entry name would overflow
> frame end of buf" entries.
> 
> I have options like this in my fstab:
> //mercury/backups/mnt/backups   cifs   
> credentials=/etc/smbcredentials,uid=kari,gid=kari,_netdev,dir_mode=0775,file_mode=0775,noperm,vers=3.0
>  0  0

Thanks for reporting back! So it might be possible that the
noserverino just makes the issue easier visible.

If I would provide you a (unsigned!) kernel-image package with a
tentative patch from upstream, asking for testing, could you boot one
affected machine into it to verify if the problem is solved?

Regards,
Salvatore

Bug#1069194: libreswan: CVE-2024-3652: IKEv1 default AH/ESP responder can crash and restart

[Salvatore Bonaccorso]

Source: libreswan
Version: 4.14-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libreswan/libreswan/issues/1665
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 4.10-2+deb12u1
Control: found -1 4.10-2
Control: found -1 4.3-1+deb11u4
Control: found -1 4.3-1

Hi,

The following vulnerability was published for libreswan.

CVE-2024-3652[0]:
| The Libreswan Project was notified of an issue causing libreswan to
| restart when using IKEv1 without specifying an esp= line. When the
| peer requests AES-GMAC, libreswan's default proposal handler causes
| an assertion failure and crashes and restarts. IKEv2 connections are
| not affected.


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-3652
https://www.cve.org/CVERecord?id=CVE-2024-3652
[1] https://github.com/libreswan/libreswan/issues/1665
[2] https://libreswan.org/security/CVE-2024-3652/CVE-2024-3652.txt

Regards,
Salvatore

Bug#1069191: glibc: GLIBC-SA-2024-0004/CVE-2024-2961: ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence

[Salvatore Bonaccorso]

Source: glibc
Version: 2.37-17
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.37-15
Control: found -1 2.36-9+deb12u5
Control: found -1 2.36-9+deb12u4
Control: found -1 2.36-9
Control: found -1 2.31-13+deb11u8
Control: found -1 2.31-13

Hi,

The following vulnerability was published for glibc.

CVE-2024-2961[0]:
| The iconv() function in the GNU C Library versions 2.39 and older
| may overflow the output buffer passed to it by up to 4 bytes when
| converting strings to the ISO-2022-CN-EXT character set, which may
| be used to crash an application or overwrite a neighbouring
| variable.


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-2961
https://www.cve.org/CVERecord?id=CVE-2024-2961
[1] https://www.openwall.com/lists/oss-security/2024/04/17/9

Regards,
Salvatore

Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

On Tue, Apr 16, 2024 at 10:49:54PM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Tue, Apr 16, 2024 at 05:46:33PM +0200, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi
> > 
> > 
> > On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> > > Package: src:linux
> > > Version: 6.1.85-1
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > >* What led up to the situation?
> > > kernel update from version 6.1.0-18 to 6.1.0-20
> > > 
> > >* What exactly did you do (or not do) that was effective (or
> > >  ineffective)?
> > > out system mounted a samba share via autofs (cifs) and we tried to access
> > > some files and directories
> > > 
> > >* What was the outcome of this action?
> > > the mount point of our share is /srv/samba/shares/company and the 
> > > directory
> > > it/MIJ had another directory "digitale kommunikation" which did not shop 
> > > up
> > > on the computer which mounted the samba share. before the kernel update it
> > > did and when we renamed the file to "digitale_kommunikation" or to 
> > > "digitalo
> > > kommunikation" we could see it.
> > > in the syslog we found the following messages:
> > > CIFS: VFS: directory entry name would overflow frame end of buf ...
> > > we could move that direcotry into another directory and it was useable, we
> > > created another directory it/abc and created the "digitale kommunikation"
> > > inside and it was hidden again. after switching back to kernel 6.1.0-20
> > > everything was ok.
> > > upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> > > 
> > >* What outcome did you expect instead?
> > > we expected to just see the "digitale kommunikation" directory as before.
> > 
> > Can you share details on how the cifs mounts are done? Which mount
> > options are used?
> > 
> > Were you able to find a minimal reproducing case which would help
> > debug the issue on non production systems?
> 
> Can you confirm you are seeing the issue only if mounting with using
> 'noserverino' mount option?
> 
> Would you be in the position of building a kernel with a commit
> reverted and verify the issue is gone with it?
> 
> If you follow
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> with the attached patch, you should be able to get a kernel image to
> test with.

I'm able to reproduce the behaviour on a test machine, when using
noserverino mount option, but I'm yet trying to further reduce the
testcase to be able to report upstream. The issue happens as well
already in 6.1.82.

Regards,
Salvatore

Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Hi,

On Tue, Apr 16, 2024 at 05:46:33PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi
> 
> 
> On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> > Package: src:linux
> > Version: 6.1.85-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > kernel update from version 6.1.0-18 to 6.1.0-20
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > out system mounted a samba share via autofs (cifs) and we tried to access
> > some files and directories
> > 
> >* What was the outcome of this action?
> > the mount point of our share is /srv/samba/shares/company and the directory
> > it/MIJ had another directory "digitale kommunikation" which did not shop up
> > on the computer which mounted the samba share. before the kernel update it
> > did and when we renamed the file to "digitale_kommunikation" or to "digitalo
> > kommunikation" we could see it.
> > in the syslog we found the following messages:
> > CIFS: VFS: directory entry name would overflow frame end of buf ...
> > we could move that direcotry into another directory and it was useable, we
> > created another directory it/abc and created the "digitale kommunikation"
> > inside and it was hidden again. after switching back to kernel 6.1.0-20
> > everything was ok.
> > upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> > 
> >* What outcome did you expect instead?
> > we expected to just see the "digitale kommunikation" directory as before.
> 
> Can you share details on how the cifs mounts are done? Which mount
> options are used?
> 
> Were you able to find a minimal reproducing case which would help
> debug the issue on non production systems?

Can you confirm you are seeing the issue only if mounting with using
'noserverino' mount option?

Would you be in the position of building a kernel with a commit
reverted and verify the issue is gone with it?

If you follow
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
with the attached patch, you should be able to get a kernel image to
test with.

Regards,
Salvatore
>From 00ab6d9874ba6adc3c8edb61c0a583e8e516ccbd Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Tue, 16 Apr 2024 22:46:24 +0200
Subject: [PATCH] Revert "smb: client: set correct d_type for reparse points
 under DFS mounts"

This reverts commit 0947d0d463d4e6fad75f3a3066613cb3d9689b26.
---
 fs/smb/client/readdir.c | 15 +++
 fs/smb/client/smb2pdu.c |  6 --
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/fs/smb/client/readdir.c b/fs/smb/client/readdir.c
index 5990bdbae598..2d75ba5aaa8a 100644
--- a/fs/smb/client/readdir.c
+++ b/fs/smb/client/readdir.c
@@ -304,16 +304,14 @@ cifs_dir_info_to_fattr(struct cifs_fattr *fattr, FILE_DIRECTORY_INFO *info,
 }
 
 static void cifs_fulldir_info_to_fattr(struct cifs_fattr *fattr,
-   const void *info,
+   SEARCH_ID_FULL_DIR_INFO *info,
    struct cifs_sb_info *cifs_sb)
 {
-	const FILE_FULL_DIRECTORY_INFO *di = info;
-
 	__dir_info_to_fattr(fattr, info);
 
-	/* See MS-FSCC 2.4.14, 2.4.19 */
+	/* See MS-FSCC 2.4.19 FileIdFullDirectoryInformation */
 	if (fattr->cf_cifsattrs & ATTR_REPARSE)
-		fattr->cf_cifstag = le32_to_cpu(di->EaSize);
+		fattr->cf_cifstag = le32_to_cpu(info->EaSize);
 	cifs_fill_common_info(fattr, cifs_sb);
 }
 
@@ -427,7 +425,7 @@ _initiate_cifs_search(const unsigned int xid, struct file *file,
 	} else if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM) {
 		cifsFile->srch_inf.info_level = SMB_FIND_FILE_ID_FULL_DIR_INFO;
 	} else /* not srvinos - BB fixme add check for backlevel? */ {
-		cifsFile->srch_inf.info_level = SMB_FIND_FILE_FULL_DIRECTORY_INFO;
+		cifsFile->srch_inf.info_level = SMB_FIND_FILE_DIRECTORY_INFO;
 	}
 
 	search_flags = CIFS_SEARCH_CLOSE_AT_END | CIFS_SEARCH_RETURN_RESUME;
@@ -1021,9 +1019,10 @@ static int cifs_filldir(char *find_entry, struct file *file,
    (FIND_FILE_STANDARD_INFO *)find_entry,
    cifs_sb);
 		break;
-	case SMB_FIND_FILE_FULL_DIRECTORY_INFO:
 	case SMB_FIND_FILE_ID_FULL_DIR_INFO:
-		cifs_fulldir_info_to_fattr(, find_entry, cifs_sb);
+		cifs_fulldir_info_to_fattr(,
+	   (SEARCH_ID_FULL_DIR_INFO *)find_entry,
+	   cifs_sb);
 		break;
 	default:
 		cifs_dir_info_to_fattr(,
diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
index cc425a616899..f95623b24405 100644
--- a/fs/smb/client/smb2pdu.c
+++ b/fs/smb/client/smb2pdu.c
@@ -5010,9 +5010,6 @@ int SMB2_query_directory_init(const unsigned int xid,
 	case SMB_FIND_FILE_POSIX_INFO:
 		req->FileInformationClass = SMB

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Salvatore Bonaccorso]

Control: forwarded -1 
https://lore.kernel.org/regressions/zh7flxvnddfat...@eldamar.lan/T/#u

Hi both,

On Tue, Apr 16, 2024 at 08:31:23PM +0200, Roland Rosenfeld wrote:
> Hi Salvatore and Diederik!
> 
> On Di, 16 Apr 2024, Salvatore Bonaccorso wrote:
> 
> > If you revert that commit, does that fix your issue? Note that it
> > opens up again as well the referenced issue, but it would be helpfull
> > for reporting as regression if we know that's the case.
> 
> Thanks to the support by Diederik, I was able to build a new kernel
> with the two patches reverted and this kernel solves the issue and
> uses the correct MAC and renames the interface to enx as before
> instead of using a random MAC and using eth0 as the inerface name.
> 
> On Di, 16 Apr 2024, Diederik de Haas wrote:
> 
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> > describes a procedure with which you can apply (the attached) patches
> 
> Thanks for this hint and pointing to the perfect chapter, which made
> building a test kernel really easy.
> 
> I used the two patches, that you suggested, they are exactly the
> reverse of the two problem patches, that lead us to this issue.

Many thanks for testing!

I have forward your found regression to the regressions list:

https://lore.kernel.org/regressions/zh7flxvnddfat...@eldamar.lan/T/#u

Regards,
Salvatore

Bug#1069127: python-idna: CVE-2024-3651

[Salvatore Bonaccorso]

Source: python-idna
Version: 3.6-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-idna.

CVE-2024-3651[0]:
| potential DoS via resource consumption via specially crafted inputs to
| idna.encode()


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-3651
https://www.cve.org/CVERecord?id=CVE-2024-3651
[1] https://github.com/kjd/idna/security/advisories/GHSA-jjg7-2v4v-x38h

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1069126: gunicorn: CVE-2024-1135

[Salvatore Bonaccorso]

Source: gunicorn
Version: 20.1.0-6
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gunicorn.

CVE-2024-1135[0]:
| Gunicorn fails to properly validate Transfer-Encoding headers,
| leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting
| requests with conflicting Transfer-Encoding headers, attackers can
| bypass security restrictions and access restricted endpoints. This
| issue is due to Gunicorn's handling of Transfer-Encoding headers,
| where it incorrectly processes requests with multiple, conflicting
| Transfer-Encoding headers, treating them as chunked regardless of
| the final encoding specified. This vulnerability allows for a range
| of attacks including cache poisoning, session manipulation, and data
| exposure.


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-1135
https://www.cve.org/CVERecord?id=CVE-2024-1135
[1] https://huntr.com/bounties/22158e34-cfd5-41ad-97e0-a780773d96c1
[2] 
https://github.com/benoitc/gunicorn/commit/ac29c9b0a758d21f1e0fb3b3457239e523fa9f1d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi


On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> Package: src:linux
> Version: 6.1.85-1
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> kernel update from version 6.1.0-18 to 6.1.0-20
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> out system mounted a samba share via autofs (cifs) and we tried to access
> some files and directories
> 
>* What was the outcome of this action?
> the mount point of our share is /srv/samba/shares/company and the directory
> it/MIJ had another directory "digitale kommunikation" which did not shop up
> on the computer which mounted the samba share. before the kernel update it
> did and when we renamed the file to "digitale_kommunikation" or to "digitalo
> kommunikation" we could see it.
> in the syslog we found the following messages:
> CIFS: VFS: directory entry name would overflow frame end of buf ...
> we could move that direcotry into another directory and it was useable, we
> created another directory it/abc and created the "digitale kommunikation"
> inside and it was hidden again. after switching back to kernel 6.1.0-20
> everything was ok.
> upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> 
>* What outcome did you expect instead?
> we expected to just see the "digitale kommunikation" directory as before.

Can you share details on how the cifs mounts are done? Which mount
options are used?

Were you able to find a minimal reproducing case which would help
debug the issue on non production systems?

Regards,
Salvatore

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Roland,

On Tue, Apr 16, 2024 at 09:29:28AM +0200, Roland Rosenfeld wrote:
> Package: src:linux
> Version: 6.1.85-1
> Severity: important
> 
> Dear Maintainer,
> 
> when upgrading from 6.1.76-1 to 6.1.85-1 my USB ethernet device
>  ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
> is no longer named enx00249bXX but eth0.
> 
> I see the following in dmsg:
> 
> [1.484345] usb 4-5: Manufacturer: ASIX Elec. Corp.
> [1.484661] usb 4-5: SerialNumber: 249BXX
> [1.496312] ax88179_178a 4-5:1.0 eth0: register 'ax88179_178a' at 
> usb-:00:14.0-5, ASIX AX88179 USB 3.0 Gigabit Ethernet, d2:60:4c:YY:YY:YY
> [1.497746] usbcore: registered new interface driver ax88179_178a
> 
> Unplugging and plugging again does not solve the issue, but the
> interface still is named eth0.
> 
> Maybe it has to do with the following commit from
> https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.85
> 
> commit fc77240f6316d17fc58a8881927c3732b1d75d51
> Author: Jose Ignacio Tornos Martinez 
> Date:   Wed Apr 3 15:21:58 2024 +0200
> 
> net: usb: ax88179_178a: avoid the interface always configured as random 
> address
> 
> commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream.
> 
> After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
> consecutive device resets"), reset is not executed from bind operation and
> mac address is not read from the device registers or the devicetree at 
> that
> moment. Since the check to configure if the assigned mac address is random
> or not for the interface, happens after the bind operation from
> usbnet_probe, the interface keeps configured as random address, although 
> the
> address is correctly read and set during open operation (the only reset
> now).
> 
> In order to keep only one reset for the device and to avoid the interface
> always configured as random address, after reset, configure correctly the
> suitable field from the driver, if the mac address is read successfully 
> from
> the device registers or the devicetree. Take into account if a locally
> administered address (random) was previously stored.
> 
> cc: sta...@vger.kernel.org # 6.6+
> Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive 
> device resets")
> Reported-by: Dave Stevenson  
> Signed-off-by: Jose Ignacio Tornos Martinez 
> Reviewed-by: Simon Horman 
> Link: 
> https://lore.kernel.org/r/20240403132158.344838-1-jtorn...@redhat.com
> Signed-off-by: Jakub Kicinski 
> Signed-off-by: Greg Kroah-Hartman 
> 
> Seems, that I'm not alone with this issue, there are also reports in
> https://www.reddit.com/r/debian/comments/1c304xn/linuximageamd64_61851_usb_link_interface_names/
> and https://infosec.space/@topher/112276500329020316
> 
> 
> All other (pci based) network interfaces still use there static names
> (enp0s25, enp2s0, enp3s0), only the usb ethernet name is broken with
> the new kernel.

If you revert that commit, does that fix your issue? Note that it
opens up again as well the referenced issue, but it would be helpfull
for reporting as regression if we know that's the case.

Regards,
Salvatore

Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)

[Salvatore Bonaccorso]

Hi Martin,

On Tue, Apr 16, 2024 at 09:26:02AM +0200, Martin Pitt wrote:
> Control: tag -1 upstream fixed-upstream patch
> Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/19790
> 
> Hello Salvatore and Santiago,
> 
> Salvatore Bonaccorso [2024-04-15 19:28 +0200]:
> > The update for cockpit in DSA 5655-1 had problems with the
> > test-sshbridge test, causing FTBFS:
> >
> > >From the tail of the test failure:
> >
> > # cockpit-protocol-DEBUG: test-ssh: output queue empty
> >
> > (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702: 
> > (src/ssh/cockpitsshrelay.c:1423):cockpit_ssh_connect: runtime check failed: 
> > (ssh_options_set (data->session, SSH_OPTIONS_HOST, host) == 0)
> >
> > (cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702: 
> > (src/ssh/cockpitsshrelay.c:1424):cockpit_ssh_connect: runtime check failed: 
> > (ssh_options_parse_config (data->session, NULL) == 0)
> > # cockpit-protocol-DEBUG: test-ssh: reading input 1
> > # cockpit-protocol-DEBUG: test-ssh: received a 82 byte payload
> > # cockpit-protocol-DEBUG: test-ssh: want more data
> > **
> > cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init: 
> > assertion failed (json_object_get_string_member (init, "command") == 
> > "init"): ("authorize" == "init")
> > Bail out! 
> > cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init: 
> > assertion failed (json_object_get_string_member (init, "command") == 
> > "init"): ("authorize" == "init")
> > cockpit-ssh-Message: 20:51:17.704: cockpit-ssh some_host: -1 couldn't 
> > connect: Hostname required 'some_host' '22'
> > cockpit-ssh-Message: 20:51:17.704: couldn't write control message: Broken 
> > pipe
> > cockpit-ssh-Message: 20:51:17.704: couldn't write authorize message: 
> > Inappropriate ioctl for device
> > FAIL test-sshbridge (exit status: 134)
> 
> Argh, I can reproduce. The test passes with the previous
> http://snapshot.debian.org/package/libssh/0.10.5-3/ but fails with current 
> 0.10.6-0+deb12u1.
> 
> The reason is annoyingly mundane, and already got fixed upstream half a year 
> ago:
> https://github.com/cockpit-project/cockpit/commit/518d36c3492020525
> 
> I prepared a package update with that fix cherry-picked. See attached debdiff.
> It builds fine in a clean bookworm container now.
> But I don't know how exactly to target and upload this: to bookworm-security 
> or
> -updates? It's a follow-up for a previous security update to make that 
> actually
> work, but not a security update in itself.

Technically speaking, as the issue is present already before the DSA
release, you are right and the proposed update way would have been the
way to go. *But* we have a released security-update wich de-facto does
not reach the users right now, so I propose to release the regression
fix trough a security and make it a DSA regression announce.

Can you please upload to security-master?

Regards,
Salvatore

Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)

[Salvatore Bonaccorso]

Source: cockpit
Version: 287.1-0+deb12u1
Severity: serious
Justification: missing binary builds, FTBFS
X-Debbugs-Cc: t...@security.debian.org, a...@debian.org, car...@debian.org

Hi

The update for cockpit in DSA 5655-1 had problems with the
test-sshbridge test, causing FTBFS:

>From the tail of the test failure:

# cockpit-protocol-DEBUG: test-ssh: output queue empty

(cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702: 
(src/ssh/cockpitsshrelay.c:1423):cockpit_ssh_connect: runtime check failed: 
(ssh_options_set (data->session, SSH_OPTIONS_HOST, host) == 0)

(cockpit-ssh:3731): cockpit-ssh-WARNING **: 20:51:17.702: 
(src/ssh/cockpitsshrelay.c:1424):cockpit_ssh_connect: runtime check failed: 
(ssh_options_parse_config (data->session, NULL) == 0)
# cockpit-protocol-DEBUG: test-ssh: reading input 1
# cockpit-protocol-DEBUG: test-ssh: received a 82 byte payload
# cockpit-protocol-DEBUG: test-ssh: want more data
**
cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init: 
assertion failed (json_object_get_string_member (init, "command") == "init"): 
("authorize" == "init")
Bail out! 
cockpit-ssh:ERROR:src/ssh/test-sshbridge.c:560:wait_until_transport_init: 
assertion failed (json_object_get_string_member (init, "command") == "init"): 
("authorize" == "init")
cockpit-ssh-Message: 20:51:17.704: cockpit-ssh some_host: -1 couldn't connect: 
Hostname required 'some_host' '22'
cockpit-ssh-Message: 20:51:17.704: couldn't write control message: Broken pipe
cockpit-ssh-Message: 20:51:17.704: couldn't write authorize message: 
Inappropriate ioctl for device
FAIL test-sshbridge (exit status: 134)

Regards,
Salvatore

Bug#1068939: openexr: CVE-2024-31047

[Salvatore Bonaccorso]

Source: openexr
Version: 3.1.5-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/AcademySoftwareFoundation/openexr/issues/1680
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for openexr.

CVE-2024-31047[0]:
| An issue in Academy Software Foundation openexr v.3.2.3 and before
| allows a local attacker to cause a denial of service (DoS) via the
| convert function of exrmultipart.cpp.


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-31047
https://www.cve.org/CVERecord?id=CVE-2024-31047
[1] https://github.com/AcademySoftwareFoundation/openexr/issues/1680
[2] https://github.com/AcademySoftwareFoundation/openexr/pull/1681
[3] 
https://github.com/AcademySoftwareFoundation/openexr/commit/7aa89e1d09b09d9f5dbb96976ee083a331ab9d71

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068938: less: CVE-2024-32487: with LESSOPEN mishandles \n in paths

[Salvatore Bonaccorso]

Source: less
Version: 590-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for less.

CVE-2024-32487[0]:
| less through 653 allows OS command execution via a newline character
| in the name of a file, because quoting is mishandled in filename.c.
| Exploitation typically requires use with attacker-controlled file
| names, such as the files extracted from an untrusted archive.
| Exploitation also requires the LESSOPEN environment variable, but
| this is set by default in many common cases.


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-32487
https://www.cve.org/CVERecord?id=CVE-2024-32487
[1] https://www.openwall.com/lists/oss-security/2024/04/12/5

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1

[Salvatore Bonaccorso]

Hi Sebastian,

On Tue, Apr 09, 2024 at 06:18:13PM +0200, Sebastian Andrzej Siewior wrote:
> On 2024-04-07 23:46:28 [+0200], To Adam D. Barratt wrote:
> > On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote:
> > > 
> > > Sorry for not getting to this sooner. Is this still the case?
> > 
> > So. This happened #1068045 (yapet broke with 1.0 format) due to the
> > update. On the bright side it has been broken in unstable but unnoticed.
> > Looking into it but also sleeping (but making progress).
> 
> yapet is fixed in unstable. My understanding is that the maintainer will
> take care of it.

After exposure of the upload in unstable for two days, uploaded now as
well to bookworm. Filled #1068836.

Regards,
Salvatore

Bug#1068836: bookworm-pu: package yapet/2.6-2~deb12u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ya...@packages.debian.org, car...@debian.org
Control: affects -1 + src:yapet
User: release.debian@packages.debian.org
Usertags: pu

Hi,

[ Reason ]
After the update of openssl/3.0.13-1~deb12u1 in bookworm-pu Sean found
that old 1.0 format databases. While most of people should have moved
some time ago to 2.0 format databases, they are still claimed to be
supported. The update of openssl uncovered though a bug in yapet (as
well present in unstable, and fixed as well).

Sebastian explained the situation in https://bugs.debian.org/1068045#94

[ Impact ]
Users using the old 1.0 format could not open anymore their store.

[ Tests ]
Done explicitly with an old 1.0 format database provided by sean,
running the testsuite, and manual checks with 2.0 format databases.

[ Risks ]
Patches provided by the openssl maintainer. While they are not yet
applied upstream, they tackle the bug in yapet as isolated by the
openssl maintainers.

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

[ Changes ]
The two patches drop EVP_CIPHER_CTX_set_key_length() invocation to
keep compatiblity with 1.0 databases and with openssl versions.
Quoting the commit:

|yapet did for blowfish:
|
|| EVP_CipherInit_ex(ctx, cipher, NULL, KEY, iv, mode);
|| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
|| EVP_CipherUpdate(ctx, …);
|
|this worked in earlier OpenSSL versions and stopped working in
|openssl-3.0.13. The problem here is that the
|EVP_CIPHER_CTX_set_key_length() is ignored and the later OpenSSL version
|returns rightfully an error "Provider routines::no key set" here.
|
|Blowfish does support variable key lenghts but the key length has to be
|set first followed by the actual key. Otherwise the blocksize (16) will
|be used.
|The correct way to deal with this would be:
|| EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, mode);
|| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
|| EVP_CipherInit_ex(ctx, NULL, NULL, KEY, IV, mode);
|| EVP_CipherUpdate(ctx, …);
|
|Using now the proper way will break earlier databases because in the
|blowfish case, always the default blocksize / 16 has been used.
|
|In order to keep compatibility with earlier versions of the database and
|openssl remove the EVP_CIPHER_CTX_set_key_length() invocation.

While at it Sebastian fixed as well the invocation present for the
crypt/aes code.

[ Other info ]
None.

Regards,
Salvatore
diff -Nru yapet-2.6/debian/changelog yapet-2.6/debian/changelog
--- yapet-2.6/debian/changelog  2022-03-14 14:19:11.0 +0100
+++ yapet-2.6/debian/changelog  2024-04-11 20:40:18.0 +0200
@@ -1,3 +1,16 @@
+yapet (2.6-2~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm
+
+ -- Salvatore Bonaccorso   Thu, 11 Apr 2024 20:40:18 +0200
+
+yapet (2.6-2) unstable; urgency=medium
+
+  * crypt/blowfish: Remove EVP_CIPHER_CTX_set_key_length() (Closes: #1064724)
+  * crypt/aes: Remove EVP_CIPHER_CTX_set_key_length()
+
+ -- Salvatore Bonaccorso   Mon, 08 Apr 2024 21:32:50 +0200
+
 yapet (2.6-1) unstable; urgency=medium
 
   * New upstream version 2.6
diff -Nru 
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch 
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
--- 
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch   
1970-01-01 01:00:00.0 +0100
+++ 
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch   
2024-04-11 20:40:18.0 +0200
@@ -0,0 +1,41 @@
+From aaa573b14bafcc9a6b46495bd4ffc15b90d35902 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Mon, 8 Apr 2024 18:19:12 +0200
+Subject: [PATCH] crypt/aes: Remove EVP_CIPHER_CTX_set_key_length().
+
+The EVP_CIPHER_CTX_set_key_length() in the AES-256-CBC case is pointless
+because the key here is fixed EVP_CIPHER_CTX_set_key_length() and the
+function does not change the size.
+
+Remove the EVP_CIPHER_CTX_set_key_length() invocation.
+
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ src/libs/crypt/aes256.cc | 11 ---
+ 1 file changed, 11 deletions(-)
+
+diff --git a/src/libs/crypt/aes256.cc b/src/libs/crypt/aes256.cc
+index 1041b9c57347..e105b1a5bedd 100644
+--- a/src/libs/crypt/aes256.cc
 b/src/libs/crypt/aes256.cc
+@@ -113,17 +113,6 @@ EVP_CIPHER_CTX* Aes256::initializeOrThrow(const 
SecureArray& ivec, MODE mode) {
+ throw CipherError{_("Error initializing cipher")};
+ }
+ 
+-success = EVP_CIPHER_CTX_set_key_length(context, getKey()->keySize());
+-if (success != SSL_SUCCESS) {
+-LOG_MESSAGE(std::string{__func__} + ": Error setting key length");
+-destroyContext(context);
+-char msg[YAPET::Consts::EXCEPTION_MESSAGE_BUFF

Bug#1068770: linux-image-6.1.0-18-amd64: Local privilege escalation vulnerability in kernel n_gsm driver

[Salvatore Bonaccorso]

Control: tags -1 + confirmed pending
Control: found -1 6.1.82-1

Hi,

On Wed, Apr 10, 2024 at 12:16:21PM -0700, LW wrote:
> Package: src:linux
> Version: 6.1.76-1
> Severity: critical
> Tags: upstream security
> Justification: root security hole
> X-Debbugs-Cc: lw-deb-...@greyskydesigns.com, Debian Security Team 
> 
> 
> Dear Maintainer,
> 
> A Reddit thread[1] linked to a Github page[2] with a local root
> escalation exploit.  This exploit works on the current "bookworm"
> stable kernel, 6.1.0-18-amd64.
> 
> It can be worked around by blocking the n_gsm driver:
> 
> echo 'blacklist n_gsm' | sudo tee -a /etc/modprobe.d/blacklist-gsm.conf
> sudo rmmod n_gsm
> 
> 
> [1] 
> https://old.reddit.com/r/linux/comments/1c0i7tx/someone_found_a_kernel_0day/
> [2] https://github.com/YuriiCrimson/ExploitGSM/

Thanks we are already aware of the issue.

Upstream is going to apply a mitigation for the issue:
https://lore.kernel.org/stable/2024041054-asleep-replace-96e8@gregkh/T/#m3a8ce43359ad57e447faa4db6ecf4f4c1b60c498

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

Control: tags -1 + upstream

Hi,

On Wed, Apr 10, 2024 at 07:00:14PM +0200, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-04-10):
> > Intermediate results based on upstream stable releases: v6.1.80 is good,
> > v6.1.81 is bad. Still ~200 commits to bisect.
> 
> Final results:
> 
> kibi@genova:~/hack/linux.git ((cf33e6ca12d81...)|BISECTING)$ git bisect 
> bad
> cf33e6ca12d814e1be2263cb76960d0019d7fb94 is the first bad commit
> commit cf33e6ca12d814e1be2263cb76960d0019d7fb94
> Author: Mike Christie 
> Date:   Thu Dec 29 13:01:40 2022 -0600
> 
> scsi: core: Add struct for args to execution functions
> 
> [ Upstream commit d0949565811f0896c1c7e781ab2ad99d34273fdf ]
> 
> Move the SCSI execution functions to use a struct for passing in 
> optional
> args. This commit adds the new struct, temporarily converts 
> scsi_execute()
> and scsi_execute_req() ands a new helper, scsi_execute_cmd(), which 
> takes
> the scsi_exec_args struct.
> 
> There should be no change in behavior. We no longer allow users to 
> pass in
> any request->rq_flags value, but they were only passing in RQF_PM 
> which we
> do support by allowing users to pass in the BLK_MQ_REQ flags used by
> blk_mq_alloc_request().
> 
> Subsequent commits will convert scsi_execute() and scsi_execute_req() 
> users
> to the new helpers then remove scsi_execute() and scsi_execute_req().
> 
> Signed-off-by: Mike Christie 
> Reviewed-by: Bart Van Assche 
> Reviewed-by: Christoph Hellwig 
> Reviewed-by: John Garry 
> Signed-off-by: Martin K. Petersen 
> Stable-dep-of: 321da3dc1f3c ("scsi: sd: usb_storage: uas: Access 
> media prior to querying device properties")
> Signed-off-by: Sasha Levin 
> 
>  drivers/scsi/scsi_lib.c| 52 
> ++
>  include/scsi/scsi_device.h | 51 
> -
>  2 files changed, 62 insertions(+), 41 deletions(-)
> 
> 
> That's one of the 3 commits suggested by Diederik, good hunch.
> 
> I know hindsight is always 100% but “There should be no change in
> behavior.”… :D
> 
> Of course, since there are companion changes afterwards, it cannot be
> simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).
> 
> 
> I'd appreciate if someone could carry the ball through the appropriate
> channels upstream.

Great, thanks a lot for your bisecting work!

Yes, if you prefer to not do the forwarding upstream (stable list, CC
to involved people + regression list), then I can try to take care of
it. Obviously the former would be great, as you are the finder and
have done all the work.

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

On Wed, Apr 10, 2024 at 03:42:44PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 + confirmed
> 
> hi Cyril,
> 
> On Wed, Apr 10, 2024 at 03:32:02PM +0200, Cyril Brulebois wrote:
> > Cyril Brulebois  (2024-04-10):
> > > Salvatore Bonaccorso  (2024-04-10):
> > > > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > > > Does the problem go away if you revert the following commits on top 
> > > > > of -19?
> > > > > 
> > > > > db6338f45971b4285ea368432a84033690eaf53c
> > > > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH 
> > > > > handler
> > > > > 
> > > > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > > > scsi: core: Move scsi_host_busy() out of host lock if it is for 
> > > > > per-command
> > > > > 
> > > > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > > > scsi: core: Add struct for args to execution functions
> > > 
> > > Preparing that test right now, thanks Diederik.
> > 
> > This doesn't build, but I didn't try very hard:
> > 
> > /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function 
> > ‘sd_read_block_zero’:
> > /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error: 
> > implicit declaration of function ‘scsi_execute_cmd’; did you mean 
> > ‘scsi_execute_req’? [-Werror=implicit-function-declaration]
> > 
> > > > Or if that does not find the culprit, would you be able to bisect the
> > > > upstrema changes beweeen 6.1.76 and 6.1.82?
> > 
> > I think I'll try and pinpoint when that regression came up, then figure
> > out what to try to get rid of it. Also testing v6.1.84 while I'm at it.
> > 
> > > > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices 
> > > > > to standby")
> > 
> > Reverting that one got me a successful build but that didn't help.
> > 
> > 
> > I'll need to find some more time to switch from throwing a patch into
> > the packaging repository to bindeb-pkg'ing from the mainline repository,
> > and to automate testing as much as possible. I'm familiar with the
> > exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
> > required in the amd64 case.
> 
> FWIW, I can reproduce the issue myself as well, so that makes us both
> already bit more independent to debug the issue.

6.7.9-2 in unstable does not exibit the issue.

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo
Control: tags -1 + confirmed

hi Cyril,

On Wed, Apr 10, 2024 at 03:32:02PM +0200, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-04-10):
> > Salvatore Bonaccorso  (2024-04-10):
> > > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > > Does the problem go away if you revert the following commits on top of 
> > > > -19?
> > > > 
> > > > db6338f45971b4285ea368432a84033690eaf53c
> > > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH 
> > > > handler
> > > > 
> > > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > > scsi: core: Move scsi_host_busy() out of host lock if it is for 
> > > > per-command
> > > > 
> > > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > > scsi: core: Add struct for args to execution functions
> > 
> > Preparing that test right now, thanks Diederik.
> 
> This doesn't build, but I didn't try very hard:
> 
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function 
> ‘sd_read_block_zero’:
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error: 
> implicit declaration of function ‘scsi_execute_cmd’; did you mean 
> ‘scsi_execute_req’? [-Werror=implicit-function-declaration]
> 
> > > Or if that does not find the culprit, would you be able to bisect the
> > > upstrema changes beweeen 6.1.76 and 6.1.82?
> 
> I think I'll try and pinpoint when that regression came up, then figure
> out what to try to get rid of it. Also testing v6.1.84 while I'm at it.
> 
> > > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to 
> > > > standby")
> 
> Reverting that one got me a successful build but that didn't help.
> 
> 
> I'll need to find some more time to switch from throwing a patch into
> the packaging repository to bindeb-pkg'ing from the mainline repository,
> and to automate testing as much as possible. I'm familiar with the
> exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
> required in the amd64 case.

FWIW, I can reproduce the issue myself as well, so that makes us both
already bit more independent to debug the issue.

Regards,
Salvatore

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo 

Cyril,

On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> Hi Cyril,
> 
> On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> > Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> > leads to losing some SMART information, at least as queried by munin (in
> > Debian 12) when it comes to sensors.
> 
> Does the problem go away if you revert the following commits on top of -19?
> 
> db6338f45971b4285ea368432a84033690eaf53c
> scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
> 
> 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
> 
> cf33e6ca12d814e1be2263cb76960d0019d7fb94
> scsi: core: Add struct for args to execution functions

Or if that does not find the culprit, would you be able to bisect the
upstrema changes beweeen 6.1.76 and 6.1.82?

There would be for instance the following ata related change:

4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to standby")

If you can test it with other kernels, does the same happens on
6.7.7-1 and 6.7.9-2?

Regards,
Salvatore

Bug#1066883: alg: ecdh-nist-p256: test failed on vector 2, err=-14

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Thu, Mar 14, 2024 at 09:41:18PM +, Tj wrote:
> Source: linux
> Severity: important
> 
> Same as: Bug #1061262
> 
> I've been seeing this with builds since 6.7 cycle started. It seems to
> show up mostly for hosts with bluetooth hardware since the bluetooth
> module depends on ecdh. The trace indicates ecdh_generic is still
> loading when the test is attempted.
> 
> journalctl --grep 'alg: self-tests for ecdh-nist-p256' | 
>   grep -- '-- Boot' |
> while read -r a b hash d; do
> journalctl --boot $hash | head -n 1 | 
> grep -oE 'version [^ ]+'
> done |
> sort -u
> 
> version 6.7.0-rc5+debian+tj
> version 6.7.1+debian+tj
> version 6.7.4+debian+tj
> version 6.8.0+debian+tj
> 
> crypto algo self-tests 'alg: ecdh-nist-p256: test failed on vector 2, err=-14
> 
> -14 is "EFAULT 14 / Bad address */
> 
> and the log shows
> 
> Modules linked in: ecdh_generic(+) ...
> 
> where the "(+)" means module loading.
> 
> This only seems to occur on hosts with Bluetooth hardware and "bluetooth" 
> module (requires ECDH) when those modules are in the initrd.img.
> 
> It feels like the self-tests are running before the module is fully loaded - 
> in fact the tcrypt module (CONFIG_CRYPTO_TEST) isn't loaded according to 
> "Modules linked in:" report and it isn't contained in the initrd.img so these 
> tests seem to be occuring without it.
> 
> root@t300chi:/tmp/initrd# unmkinitramfs /boot/initrd.img-6.8.0+debian+tj .
> root@t300chi:/tmp/initrd# ls
> early  main
> root@t300chi:/tmp/initrd# ls 
> main/usr/lib/modules/6.8.0+debian+tj/kernel/crypto/
> af_alg.ko  algif_skcipher.ko  async_tx  crc32c_generic.ko  
> crct10dif_common.ko  crct10dif_generic.ko  ecc.ko  ecdh_generic.ko  xor.ko  
> xts.ko
> root@t300chi:/tmp/initrd# ls 
> main/usr/lib/modules/6.8.0+debian+tj/kernel/drivers/bluetooth/
> btbcm.ko  btintel.ko  btmtk.ko  btrtl.ko  btusb.ko
> root@t300chi:/tmp/initrd# ls 
> main/usr/lib/modules/6.8.0+debian+tj/kernel/net/bluetooth/
> bluetooth.ko
> root@t300chi:/tmp/initrd# find  . /usr/lib/modules/6.8.0+debian+tj/kernel  
> -type f -name '*tcrypt*'
> /usr/lib/modules/6.8.0+debian+tj/kernel/crypto/tcrypt.ko.xz
> 
> 
> Mar 14 06:30:29 t300chi kernel: alg: ecdh-nist-p256: test failed on vector 2, 
> err=-14
> Mar 14 06:30:29 t300chi kernel: alg: self-tests for ecdh-nist-p256 using 
> ecdh-nist-p256-generic failed (rc=-14)
> Mar 14 06:30:29 t300chi kernel: [ cut here ]
> Mar 14 06:30:29 t300chi kernel: alg: self-tests for ecdh-nist-p256 using 
> ecdh-nist-p256-generic failed (rc=-14)
> Mar 14 06:30:29 t300chi kernel: WARNING: CPU: 0 PID: 197 at 
> crypto/testmgr.c:5888 alg_test+0x42b/0x580
> Mar 14 06:30:29 t300chi kernel: Modules linked in: ecdh_generic(+) ecc crc16 
> sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic 
> crct10dif_commo>
> Mar 14 06:30:29 t300chi kernel: CPU: 0 PID: 197 Comm: cryptomgr_test Not 
> tainted 6.8.0+debian+tj #158
> Mar 14 06:30:29 t300chi kernel: Hardware name: ASUSTeK COMPUTER INC. 
> T300CHI/T300CHI, BIOS T300CHI.209 04/18/2019
> Mar 14 06:30:29 t300chi kernel: RIP: 0010:alg_test+0x42b/0x580
> Mar 14 06:30:29 t300chi kernel: Code: 89 ea 48 89 ee 4c 89 f7 e8 d2 e8 ff ff 
> 41 89 c0 e9 36 fd ff ff 44 89 c1 48 89 ea 4c 89 e6 48 c7 c7 58 9c 2b 8a e8 b5 
> 0>
> Mar 14 06:30:29 t300chi kernel: RSP: 0018:a53a80627e08 EFLAGS: 00010282
> Mar 14 06:30:29 t300chi kernel: RAX:  RBX: 1e00 
> RCX: 
> Mar 14 06:30:29 t300chi kernel: RDX: 0002 RSI: 0002 
> RDI: 
> Mar 14 06:30:29 t300chi kernel: RBP: 8e5241213800 R08: 0867 
> R09: 000a
> Mar 14 06:30:29 t300chi kernel: R10: 0001 R11: 20726f6620737473 
> R12: 8e5241213880
> Mar 14 06:30:29 t300chi kernel: R13: 0008 R14: 0078 
> R15: 
> Mar 14 06:30:29 t300chi kernel: FS:  () 
> GS:8e535700() knlGS:
> Mar 14 06:30:29 t300chi kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Mar 14 06:30:29 t300chi kernel: CR2: 7f389404ee24 CR3: 7761c001 
> CR4: 003706f0
> Mar 14 06:30:29 t300chi kernel: DR0:  DR1:  
> DR2: 
> Mar 14 06:30:29 t300chi kernel: DR3:  DR6: fffe0ff0 
> DR7: 0400
> Mar 14 06:30:29 t300chi kernel: Call Trace:
> Mar 14 06:30:29 t300chi kernel:  
> Mar 14 06:30:29 t300chi kernel:  ? alg_test+0x42b/0x580
> Mar 14 06:30:29 t300chi kernel:  ? __warn+0x7d/0x130
> Mar 14 06:30:29 t300chi kernel:  ? alg_test+0x42b/0x580
> Mar 14 06:30:29 t300chi kernel:  ? report_bug+0x18d/0x1c0
> Mar 14 06:30:29 t300chi kernel:  ? handle_bug+0x3c/0x70
> Mar 14 06:30:29 t300chi kernel:  ? exc_invalid_op+0x13/0x60
> Mar 14 06:30:29 t300chi kernel:  ? asm_exc_invalid_op+0x16/0x20
> Mar 14 06:30:29 t300chi 

Bug#1068633: bookworm-pu: package cjson/1.7.15-1+deb12u1

[Salvatore Bonaccorso]

Hi,

Disclaimer, this is not an authoritative answer as I'm not part of the
stable release managers.

On Mon, Apr 08, 2024 at 12:27:50PM +0300, Maytham Alsudany wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: cj...@packages.debian.org
> Control: affects -1 + src:cjson
> 
> [ Reason ]
> CVE-2023-50472, CVE-2023-50471
> 
> [ Impact ]
> Segmentation violation via the function cJSON_InsertItemInArray at cJSON.c
> 
> [ Tests ]
> Upstream's test continue to pass, and they have also added new tests to
> cover this security issue.
> 
> [ Risks ]
> Minimal, no change to API. Only minimal changes were made to fix this
> security issue.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> - Set myself as Maintainer (I am adopting the package, #1067510)
> - Bump Standards-Version to 4.6.2
> - Add Build-Depends-Package to symbools
> - Backport upstream's patch to 'add NULL checkings'.
>   Upstream adds a few more if statements to avoid the segmentation
>   fault, and thus resolve the security vulnerability.
> 
> [ Other info ]
> If you can spare the time, could you please upload this for me? (I need
> a sponsor, #1068624.) I'm also still waiting for someone to give me
> access to the Salsa repo.
> 
> Thanks,
> Maytham

> diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
> --- cjson-1.7.15/debian/changelog 2021-08-29 23:30:06.0 +0300
> +++ cjson-1.7.15/debian/changelog 2024-04-03 06:57:10.0 +0300
> @@ -1,3 +1,13 @@
> +cjson (1.7.15-1+deb12u1) bookworm-security; urgency=medium

The target distribution should be simply bookworm.

> +
> +  * Update Maintainer field
> +  * Bump Standards-Version to 4.6.2 (no changes)

This is usually not allowed to do in a stable update.

> +  * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
> +(Closes: #1059287)
> +  * Add Build-Depends-Package to symbols

While this might be sensible, I'm not sure if SRM will accept it.

So you might want to adjust already the things above and seek for an
ack from SRM.

Regards,
Salvatore

Bug#1068658: openssl: CVE-2024-2511

[Salvatore Bonaccorso]

Source: openssl
Version: 3.2.1-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.1.5-1
Control: found -1 3.0.11-1~deb12u2

Hi,

The following vulnerability was published for openssl.

CVE-2024-2511[0]:
| Issue summary: Some non-default TLS server configurations can cause
| unbounded memory growth when processing TLSv1.3 sessions  Impact
| summary: An attacker may exploit certain server configurations to
| trigger unbounded memory growth that would lead to a Denial of
| Service  This problem can occur in TLSv1.3 if the non-default
| SSL_OP_NO_TICKET option is being used (but not if early_data support
| is also configured and the default anti-replay protection is in
| use). In this case, under certain conditions, the session cache can
| get into an incorrect state and it will fail to flush properly as it
| fills. The session cache will continue to grow in an unbounded
| manner. A malicious client could deliberately create the scenario
| for this failure to force a Denial of Service. It may also happen by
| accident in normal operation.  This issue only affects TLS servers
| supporting TLSv1.3. It does not affect TLS clients.  The FIPS
| modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
| 1.0.2 is also not affected by 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-2511
https://www.cve.org/CVERecord?id=CVE-2024-2511
[1] https://www.openssl.org/news/secadv/20240408.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068631: linux-image-6.6.15-amd64: Using monitor refreshrate above 120Hz i get random black screen for a few seconds at certain actions

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Mon, Apr 08, 2024 at 04:44:12PM +0800, dada007 wrote:
> Package: src:linux
> Version: 6.6.15-2
> Severity: important
> X-Debbugs-Cc: peter_malmb...@proton.me
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation? has been the same problem since kernel 6.5
> came out, just opening a browser with or another app makes the screen go 
> black,
> like it is switching mode or graphics card or something. Not all apps give 
> this
> problem, but many.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I had an earlier report with this bug. I came in contact
> with Diederik de Haas, he told me to install apt install ./linux-
> image-6.5.0-0-rt-amd64_6.5~rc4-1~exp1_amd64.deb, I did and with that kernel
> there was no problem. But i guess it never got upstreamed to the next real
> kernel?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

Can you confirm, does the same happen with the kernel currently in
unstable? (6.7.9-2).

Regards,
Salvatore

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Salvatore Bonaccorso]

Hi Sebastian,

On Mon, Apr 08, 2024 at 06:43:01PM +0200, Sebastian Andrzej Siewior wrote:
> control: tags -1 patch
> control: reassign -1 yapet 2.6-1
> 
> On 2024-04-08 08:32:58 [+0200], Kurt Roeckx wrote:
> > There might be a related change that doesn't allow restarting the
> > operation with the same context without setting things up again.
> 
> Yapet is broken and the openssl update revealed the problem. I
> reassigned it to yapet 2.6 but probably affects earlier versions.
> But then the 1.1.1 series is no longer maintained so…
> 
> Patches attached and they hold the details of why and such.
> 
> This needs to be applied to unstable and Bookworm.
> The testsuite passes and I can open Sean's test file.
> Further testing is welcome by actual users ;)

Thanks for the investigation and bringing the fixes to upstream
already: https://github.com/RafaelOstertag/yapet/pull/29
> 
> I can NMU if needed just yell.

No need for that, will take it with my maintainers hat on from here.

Regards,
Salvatore

Bug#1068346: [ftpmas...@ftp-master.debian.org: Accepted node-express 4.19.2+~cs8.36.21-1 (source) into unstable]

[Salvatore Bonaccorso]

Source: node-express
Source-Version: 4.19.2+~cs8.36.21-1

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 07 Apr 2024 07:52:14 +0400
Source: node-express
Architecture: source
Version: 4.19.2+~cs8.36.21-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 

Changed-By: Yadd 
Changes:
 node-express (4.19.2+~cs8.36.21-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 4.19.2+~cs8.36.21 (Closes: CVE-2024-29041)
   * Unfuzz patches
Checksums-Sha1: 
 5acf5179d1b48d8019fa3f96fb0062d6a561e8cf 4250 
node-express_4.19.2+~cs8.36.21-1.dsc
 3ae8ab3767d98d0b682cda063c3339e1e86ccfaa 12489 
node-express_4.19.2+~cs8.36.21.orig-types-express-serve-static-core.tar.gz
 c26d4a151e60efe0084b23dc3369ebc631ed192d 2699 
node-express_4.19.2+~cs8.36.21.orig-types-express.tar.gz
 0de8181cc5ac0334fbe0142b510ea66ad45920bb 148014 
node-express_4.19.2+~cs8.36.21.orig.tar.gz
 54d3fc7adacc1437efb7cb729794ee6c7b942cb0 26632 
node-express_4.19.2+~cs8.36.21-1.debian.tar.xz
Checksums-Sha256: 
 3a82fb4c483ebd00803a1b7318959c6e3ac36b1f65de447efc41173b7a603aaa 4250 
node-express_4.19.2+~cs8.36.21-1.dsc
 341f919fe2c4929497bac01a6dc29ed8b50485aa2f282896e7532b58bff88399 12489 
node-express_4.19.2+~cs8.36.21.orig-types-express-serve-static-core.tar.gz
 d292c477ae1b654d6422d7a168a86b7a680f8f0e176e854d6c7ce02e3e202f57 2699 
node-express_4.19.2+~cs8.36.21.orig-types-express.tar.gz
 08542d21662fead677b6d262ac98383030804b0e5a6c75bca9697dfd7260891a 148014 
node-express_4.19.2+~cs8.36.21.orig.tar.gz
 e0ce6a40be8f7df3271214924d0f566877b2dfb0afe48d04bbfa5295622cc6d5 26632 
node-express_4.19.2+~cs8.36.21-1.debian.tar.xz
Files: 
 77d68000e84f2b9cb03ab0d2e4bef6cf 4250 javascript optional 
node-express_4.19.2+~cs8.36.21-1.dsc
 152a87d8e5f6a37982f10c5be3d65948 12489 javascript optional 
node-express_4.19.2+~cs8.36.21.orig-types-express-serve-static-core.tar.gz
 50f392ae641a36e9cf75ae2eed0600f0 2699 javascript optional 
node-express_4.19.2+~cs8.36.21.orig-types-express.tar.gz
 755bb69941658f54651b08017ac2dbfb 148014 javascript optional 
node-express_4.19.2+~cs8.36.21.orig.tar.gz
 7c13d3b855af65df666a76a8946f900a 26632 javascript optional 
node-express_4.19.2+~cs8.36.21-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYSIGgACgkQ9tdMp8mZ
7ukYjA//b+Lm49hKE8Yx3KWD25S77PURUKnnmW9G78y9Drwb0aj9Xa0d3eYxzKp6
z1sYpbdGzJbMlLFKsxAbiWLEnM9hVlNbXQOuazmiGqfz/opIQqeq58iS7YK1RLCA
aVdIK9lL8TM64jMbysqr6ZoPIp09t7gFJU/anjm2KomPxvmYb7x7BHQZOjHmmQMg
VnHl+UphUFlIbLIjoLEcFosspTf9jDhJ5XEcxoM9d6LwcGnXZuJvl+GfcZ41hujF
v11VPZWCC9Vfei4kHgZDGlTHiP8LHcL7TwS9L+gHlCwhekVw3Ols3kjLuOTBhqWk
bRQsZM9LkxWQfHwqtPyLMQIFs72tcwSKivuBj6XYXqedSisj4EIAcBEOurTtlc0c
AGuX2TjFiZX3lajBG0zLqxgUsKESwvORuMAOmxhXsO9/vx3mW47BPWsZjK9c6Xgm
M4YBP23hEhip7iCstFdRAEjuEbmQMoSkR3tZxLQwS1E8K16iaLygygkZ0qvIKv+7
QQainMVjWCcZXfgMBhaMqdREoMBD2UgwXzoR/LQiZTvCt5IPqCKesNhua1cAvo2t
t8hTeNVsTp8wts54gpV5DffQrzlcR0uP/xxTfp5vr9a+l4YWsB8mnGpvNpOxNouf
FB7r0szSeITSRHJLcssKrsPSzd3CYcWECQ3GMS3zcmZtihqztGw=
=b+7+
-END PGP SIGNATURE-




- End forwarded message -

Bug#1067829: Fails to build on arm{el,hf} with 64bit time_t: export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-We

[Salvatore Bonaccorso]

ime, sizeof(flushtime), "%lld\n", (long long int)now);
 
 	for (i = 0; junction_proc_files[i] != NULL; i++) {
 		retval = junction_write_time(junction_proc_files[i], flushtime);
>From 774394df352c249775d51d5d6e3effa775096b4f Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Sat, 6 Apr 2024 20:48:43 +0200
Subject: [PATCH] junction: export-cache: cast to a type with a known size to
 ensure sprintf works
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

As reported in Debian, with the 64bit time_t transition for the armel
and armhf architecture, it was found that nfs-utils fails to compile
with:

	libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../support/include -I/usr/include/tirpc -I/usr/include/libxml2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -pipe -Wall -Wextra -Werror=strict-prototypes -Werror=missing-prototypes -Werror=missing-declarations -Werror=format=2 -Werror=undef -Werror=missing-include-dirs -Werror=strict-aliasing=2 -Werror=init-self -Werror=implicit-function-declaration -Werror=return-type -Werror=switch -Werror=overflow -Werror=parentheses -Werror=aggregate-return -Werror=unused-result -fno-strict-aliasing -Werror=format-overflow=2 -Werror=int-conversion -Werror=incompatible-pointer-types -Werror=misleading-indentation -Wno-cast-function-type -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -c xml.c  -fPIC -DPIC -o .libs/xml.o
	export-cache.c: In function ‘junction_flush_exports_cache’:
	export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
	  110 | snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
	  | ~~^ ~~~
	  |   | |
	  |   | time_t {aka long long int}
	  |   long int
	  | %lld

time_t is not guaranteed to be 64-bit, so it must be coerced into the expected
type for printf. Cast it to long long.

Reported-by: Vladimir Petko 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218540
Link: https://bugs.debian.org/1067829
Link: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2055349
Fixes: 494d22396d3d ("Add LDAP-free version of libjunction to nfs-utils")
Suggested-by: Vladimir Petko 
Signed-off-by: Salvatore Bonaccorso 
---
 support/junction/export-cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/support/junction/export-cache.c b/support/junction/export-cache.c
index 4e578c9b37b1..00187c019d60 100644
--- a/support/junction/export-cache.c
+++ b/support/junction/export-cache.c
@@ -107,7 +107,7 @@ junction_flush_exports_cache(void)
 		xlog(D_GENERAL, "%s: time(3) failed", __func__);
 		return FEDFS_ERR_SVRFAULT;
 	}
-	snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
+	snprintf(flushtime, sizeof(flushtime), "%lld\n", (long long)now);
 
 	for (i = 0; junction_proc_files[i] != NULL; i++) {
 		retval = junction_write_time(junction_proc_files[i], flushtime);
-- 
2.43.0

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Salvatore Bonaccorso]

Hi Sean,

On Sat, Apr 06, 2024 at 04:54:14PM +0800, Sean Whitton wrote:
> control: reassign -1 libssl3,yapet
> control: found -1 libssl3/3.1.5-1
> control: found -1 yapet/2.6-1
> control: retitle -1 libssl3,yapet: YAPET cannot decrypt YAPET1.0-format DB
> 
> Hello,
> 
> On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote:
> 
> >>
> >>> Also, yapet is unchanged in unstable. Is the problem there, too?
> >>
> 
> I have now confirmed that the problem is in unstable too.

As it is a regression caused by libssl3 3.0.11 based to 3.0.13, why is
it reassigned to yapet? (the regression is as well present in
unstable).

That said: You are right, opening 1.0 format databases should still
work that said, but is regressing with the openssl update. And as per
manpage: YAPET 2.0 will read and write pre YAPET 2.0 files. Pre YAPET
2.0 files are converted to YAPET 2.0 files when changing the master
password. Once converted, the files can no longer be read by pre YAPET
2.0 versions.

I can ask upstream, but currently yapet will FTBFS with problems in
the testsuite anyway, and the problems are related.

And yapet FTBFS with the new openssl in bookworm-pu in same way as in
unstable (but not with the old version).

Thus I believe #1068045 and #1064724 are actually related.

Regards,
Salvatore

Bug#1064724: yapet: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Salvatore Bonaccorso]

Hi,

On Thu, Mar 21, 2024 at 09:09:02AM +0100, Salvatore Bonaccorso wrote:
> Hi Vladimir,
> 
> On Thu, Mar 21, 2024 at 08:39:32PM +1300, Vladimir Petko wrote:
> > Package: yapet
> > Followup-For: Bug #1064724
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu noble ubuntu-patch
> > Control: tags -1 patch
> > 
> > Dear Maintainer,
> > 
> > The package fails to build due to the recent changes in openssl.
> > I have disabled the affected tests, but probably the issue should be fixed
> > upstream.
> > 
> > When investigating test failure I've also noticed that the tests fail on 
> > armhf
> > due to the usage of std::memset that was optimized away. I have replaced the
> > call with std::fill()
> > 
> > In Ubuntu, the attached patch was applied to achieve the following:
> > 
> >   * d/p/use-std-fill.patch: use std::fill to reset memory instead of
> > std::memset. This fixes armhf test failure (LP: 2058584).
> >   * d/p/disable-blowfish-tests.patch: disable failing blowfish tests.
> > See Debian bug 1064724.
> > 
> > 
> > Thanks for considering the patch.
> 
> Thanks for your work. I would like to give upstream some time to look
> at the two reported issues.

I'm not going to apply the patch for now, as the underlying issue is
triggered due to a change in openssl. Cf. #1068045.

Regards,
Salvatore

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

[Salvatore Bonaccorso]

Hi,

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

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

Regards,
Salvatore

Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack

[Salvatore Bonaccorso]

Hi Marco,

On Thu, Apr 04, 2024 at 11:05:03AM +0200, Marco d'Itri wrote:
> On Apr 04, Salvatore Bonaccorso  wrote:
> 
> > While I do agree (and it was filled with this severity), the bug
> > severity would not be RC, varnish currently seem to lack active
> > maintainership. 
> Not anymore: https://salsa.debian.org/md/varnish/ .

Ok that are good news, thank you for taking care of it.

For CVE-2023-44487 and CVE-2024-30156 Moritz did already mark then as
"ignored" (as beeing as well too intrusive for backporting) for
bullseye and bookworm.

Regards,
Salvatore

Bug#1068412: [ftpmas...@ftp-master.debian.org: Accepted apache2 2.4.59-1 (source) into unstable]

[Salvatore Bonaccorso]

Source: apache2
Source-Version: 2.4.59-1

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 05 Apr 2024 08:08:11 +0400
Source: apache2
Built-For-Profiles: nocheck
Architecture: source
Version: 2.4.59-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Apache Maintainers 
Changed-By: Yadd 
Closes: 1032628 1054564
Changes:
 apache2 (2.4.59-1) unstable; urgency=medium
 .
   [ Stefan Fritsch ]
   * Remove old transitional packages libapache2-mod-md and
 libapache2-mod-proxy-uwsgi. Closes: #1032628
 .
   [ Yadd ]
   * mod_proxy_connect: disable AllowCONNECT by default (Closes: #1054564)
   * Refresh patches
   * New upstream version 2.4.59
   * Refresh patches
   * Update patches
   * Update test framework
Checksums-Sha1: 
 f1cf18103ca23c57beaa2985bbbe4eee1e8dff87 3334 apache2_2.4.59-1.dsc
 7a118baaed0f2131e482f93f5057038ca6c021be 9843252 apache2_2.4.59.orig.tar.gz
 837cdf46898d962c4c05642745566249fc91e52b 833 apache2_2.4.59.orig.tar.gz.asc
 3e1cad5ee1fc66d350465c1e81d7e0f88221bc01 820300 apache2_2.4.59-1.debian.tar.xz
Checksums-Sha256: 
 25e6990e65cb685f3172143648806ab0fd263a18cd412155f0d14d7ef9987428 3334 
apache2_2.4.59-1.dsc
 e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f 9843252 
apache2_2.4.59.orig.tar.gz
 0ad3f670b944ebf08c81544bc82fae9496e88d96840cd0612d8cdeaa073eb06d 833 
apache2_2.4.59.orig.tar.gz.asc
 1e869a5024215a2a9b69603daf1395840774640f7b2701ca4b7971452a0641d1 820300 
apache2_2.4.59-1.debian.tar.xz
Files: 
 3f3ee286b583f22ec5cb3efc1f0a5016 3334 httpd optional apache2_2.4.59-1.dsc
 c39d28e0777bc95631cb49958fdb6601 9843252 httpd optional 
apache2_2.4.59.orig.tar.gz
 3c342b3dcc0fe227a1fffdf9997987d0 833 httpd optional 
apache2_2.4.59.orig.tar.gz.asc
 4da024370ede9c5a75a0df725be0cdc5 820300 httpd optional 
apache2_2.4.59-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYPec8ACgkQ9tdMp8mZ
7umCiw//TB1rIA1czwHsUrdeOIT3HG9qERzBJsmsP8nyg+cIrytiGfhlt2eOmLYO
X+Wo19J98VuCmTbJClb6opAfSpvJG2AmNUl/PYAqOBzvDgR+QlEMmVXVgxUp9+Tv
0e0P2H+8U0pO3dE51VIXqYtCLTLQnLaci763ewB0oRlSWuzoVNDDahUS3iJ5e58o
btwUQQwq+2F+RBclRhuXca3dOI93UBZDsv56mxR+p2o0vpo+pQRZjHDv8tzT3bOq
/PyWusXKPDf9MXYZqwY2TgYx8v/YdDVYqzgr6Tj/VXgXEKC22pudzSv9/J5iGfHh
VHmf02Gh+0wNWmxajqK2KlxjMON/Qn6kyoAok9w5vv4HtOXBZimzdq0kDsc8EjJl
QuaBcwIAy+0EATBhjaVY7sHtM9SydJNr1f4DBBD9kEB2DKEE9n7/iFxcFfSMd52Y
xwJ4fPk1fe1ki7k/qn0VULpzf1iM3JDQE19uXyE29cSW4eJhiWvH1v+NZzzxNo+t
NtDhSIEEnUkGZSsYyg2qg5NH3e3PJMadc1nTRY6hVNzGpJlsUrCKnMOZbJsBQM6S
cNCY48ux8ziQmJNowvBVbXf6/+SH9h2+CYFRw9GZagaNe1yfErNglbn78KZqJUHw
YcXIFc96qeznRJ9zRhPdHGGeqa+nETH1lWBp6eitihkKhDjCF48=
=dQDE
-END PGP SIGNATURE-




- End forwarded message -

Bug#1068418: rust-openssl: CVE-2024-3296

[Salvatore Bonaccorso]

Source: rust-openssl
Version: 0.10.64-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/sfackler/rust-openssl/issues/2171
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rust-openssl.

CVE-2024-3296[0]:
| A timing-based side-channel exists in the rust-openssl package,
| which could be sufficient to recover a plaintext across a network in
| a Bleichenbacher-style attack. To achieve successful decryption, an
| attacker would have to be able to send a large number of trial
| messages for decryption. The vulnerability affects the legacy
| PKCS#1v1.5 RSA encryption padding mode.


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-3296
https://www.cve.org/CVERecord?id=CVE-2024-3296
[1] https://github.com/sfackler/rust-openssl/issues/2171

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068417: trafficserver: CVE-2024-31309: HTTP/2 CONTINUATION frames can be utilized for DoS attacks

[Salvatore Bonaccorso]

Source: trafficserver
Version: 9.2.3+ds-1+deb12u1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 8.1.9+ds-1~deb11u1

Hi,

The following vulnerability was published for trafficserver.

CVE-2024-31309[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-31309
https://www.cve.org/CVERecord?id=CVE-2024-31309
[1] https://www.kb.cert.org/vuls/id/421644
[2] https://github.com/apache/trafficserver/pull/11207
[3] https://github.com/apache/trafficserver/pull/11206

Regards,
Salvatore

Bug#1068415: nghttp2: CVE-2024-28182: Reading unbounded number of HTTP/2 CONTINUATION frames to cause excessive CPU usage

[Salvatore Bonaccorso]

Source: nghttp2
Version: 1.60.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 nghttp2.

CVE-2024-28182[0]:
| nghttp2 is an implementation of the Hypertext Transfer Protocol
| version 2 in C. The nghttp2 library prior to version 1.61.0 keeps
| reading the unbounded number of HTTP/2 CONTINUATION frames even
| after a stream is reset to keep HPACK context in sync.  This causes
| excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0
| mitigates this vulnerability by limiting the number of CONTINUATION
| frames it accepts per stream. There is no workaround for this
| 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-28182
https://www.cve.org/CVERecord?id=CVE-2024-28182
[1] https://github.com/nghttp2/nghttp2/security/advisories/GHSA-x6x3-gv8h-m57q

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068347: [ftpmas...@ftp-master.debian.org: Accepted nodejs 18.20.1+dfsg-1 (source) into unstable]

[Salvatore Bonaccorso]

Source: nodejs
Source-Version: 18.20.1+dfsg-1

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 03 Apr 2024 16:50:38 +0200
Source: nodejs
Architecture: source
Version: 18.20.1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 

Changed-By: Jérémy Lal 
Changes:
 nodejs (18.20.1+dfsg-1) unstable; urgency=medium
 .
   * New upstream version 18.20.1+dfsg
 + CVE-2024-27983: HTTP/2 server crash (High)
 + CVE-2024-27982: HTTP Request Smuggling (Medium)
   * Breaks libnode108, not 109
   * copyright: remove file
   * Drop build/test_dns_resolveany_bad_ancount.patch, applied
Checksums-Sha1:
 6a1c634577a5c44ffc9a8add91de854f8d52f3c6 4359 nodejs_18.20.1+dfsg-1.dsc
 2540b9b84f230689afcbf507a307d46d4ef2a411 269724 
nodejs_18.20.1+dfsg.orig-ada.tar.xz
 fe2823889f88c0ba801ec4565b302dc987f27168 274360 
nodejs_18.20.1+dfsg.orig-types-node.tar.xz
 224708ebbaaada74e786059a276dca0054fabf33 29305332 
nodejs_18.20.1+dfsg.orig.tar.xz
 85cf8906b32eaf766c2b08690fd24be97ddc619a 163104 
nodejs_18.20.1+dfsg-1.debian.tar.xz
 ffe31e7755d29173054a343fa72cc978878d4e8e 10916 
nodejs_18.20.1+dfsg-1_source.buildinfo
Checksums-Sha256:
 b8eeb8d2a7cc17dc772fa9f0817d8d294842eb8e3ea4cdf34cc59fd29baf768a 4359 
nodejs_18.20.1+dfsg-1.dsc
 0c3caa8771a2bc6ac5d32912d07383dcae8a0cf145ed6f7017cbf6b41478acd2 269724 
nodejs_18.20.1+dfsg.orig-ada.tar.xz
 ea406dd59b86fb2ab96043231d9ff763611c0fb08d5cabbaeccad770d1b34068 274360 
nodejs_18.20.1+dfsg.orig-types-node.tar.xz
 558c42f89f57a56e8d1e131fb6bb0a40f1cc844e52e2393837f932c0d8c8b31b 29305332 
nodejs_18.20.1+dfsg.orig.tar.xz
 9213d005e8a8e4e758db1e4f3f13eb22f611ce2be1d48d558cb4558d946f7f30 163104 
nodejs_18.20.1+dfsg-1.debian.tar.xz
 18067729aa2e52618b01a9dc2c6bd1dfbdbb469cce8a5b8f379fb9294947fea6 10916 
nodejs_18.20.1+dfsg-1_source.buildinfo
Files:
 0e064ee9907fcb2b19f8f6fe88215a53 4359 javascript optional 
nodejs_18.20.1+dfsg-1.dsc
 327a080764e93ab10a593efba5b84fd3 269724 javascript optional 
nodejs_18.20.1+dfsg.orig-ada.tar.xz
 93414acee8286f9dc2e1b649cda05b09 274360 javascript optional 
nodejs_18.20.1+dfsg.orig-types-node.tar.xz
 dae02efb441915a83486babec21c8186 29305332 javascript optional 
nodejs_18.20.1+dfsg.orig.tar.xz
 175f3688d3380ceb1b3fe3fbf65fe59f 163104 javascript optional 
nodejs_18.20.1+dfsg-1.debian.tar.xz
 06d37a9966050b373c0e0b13d103f9a3 10916 javascript optional 
nodejs_18.20.1+dfsg-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEA8Tnq7iA9SQwbkgVZhHAXt0583QFAmYNu8wSHGthcG91ZXJA
bWVsaXgub3JnAAoJEGYRwF7dOfN0iF8P/jgSVspzx+1vifQxluwWLsWXJSp7jgxr
f1iOvKrmf5rXb7W1FICDoa53bOd+SmIL4Lbmd066+38k90n0zKEK61hpZoA84F6C
jYekdGsGNPGoJeygJjxK99+ZEUvAAsBmtOvq5l7aLAHQJskPXZSD7zRxRbvoAt9k
PRPQKh7uqreV3LoJGOMHnSdxUHNroM89oSqzx73nLyvfjW4+/xWkXIf3+DBoycFr
X0b9PaQmlRWH3bWdYBTb5GXMNL6qkQD41YdN4KpJd3oe17qUVBfI9+VssJuN3Gii
EQ6DQni0E4nPw9AmDG9nACjbqq1QOfWiJRmCZ6bHtPxRrTdaFUJeIhxymBqFq6V+
u4hGTgLJno2HQJ/8dPNIK2cYI/NbSRhBSIx62OPvyAEeSLAUJ9coDvoZ5/euazwS
YFxlLnp0+/FqwXR2LWAw+Za5SNdSPoTbbYyE93yxBtTFBAhq7XIIf2IoEkgLkV+z
7jYXn+DGUFnthHz1e4XAfrIHagMn/hfYgyrpzp37UyLRhY2Rk3t8/Brt44lcE001
rREGxh8QYR7ECimOdpobzoXk4JbmFf2VlvYxl7mVTzRsTeuBHaHX1VH+Dy4qLGfK
vuUBF7bjIeMCkCXrahu3kW3DFsWopqcmAGIOk/mA4iQsDvMzk7hfqNqdI/JbMPPu
jGMuZfAIvxbk
=8Xn2
-END PGP SIGNATURE-




- End forwarded message -

Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack

[Salvatore Bonaccorso]

Hi Marco,

[CC'ing security team]

On Mon, Apr 01, 2024 at 04:25:05PM +0200, Marco d'Itri wrote:
> Control: found -1 5.0.0-1
> Control: fixed -1 7.4.2
> 
> On Nov 17, Salvatore Bonaccorso  wrote:
> 
> > CVE-2023-44487[0]:
> > | The HTTP/2 protocol allows a denial of service (server resource
> > | consumption) because request cancellation can reset many streams
> > | quickly, as exploited in the wild in August through October 2023.
> Fixing this issue would require backporting a significant amount of 
> new features in varnish and I do not believe that it would be practical.
> 
> I am inclined to downgrade this bug because:
> - this is just a DoS attack
> - it only concerns people using hitch for TLS termination instead of 
>   a full web server like nginx or haproxy
> 
> nginx in stable is also vulnerable, BTW.

While I do agree (and it was filled with this severity), the bug
severity would not be RC, varnish currently seem to lack active
maintainership. 

As such an RC bug keeps it out of testing until someone steps up for a
commitment maintaining varnish.

Unfortunately now varnish is back in testing due to this downgrade.

What we can do is to fill a proper RC severity varnish bug which can
be closed once someone steps up to maintain varnish as well for stable
and oldstable release cycles.

Regards,
Salvatore

Bug#1068297: bpfcc-tools: Security issue of Debian patch: code execution via environment variable

[Salvatore Bonaccorso]

Hi,

On Wed, Apr 03, 2024 at 02:31:01PM +0700, ValdikSS wrote:
> Package: bpfcc-tools
> Version: 0.26.0+ds-1
> Severity: normal
> Tags: security
> X-Debbugs-Cc: i...@valdikss.org.ru
> 
> Dear Maintainer,
> 
> Last year there was a Debian fix for the upstream issue of bpfcc package
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028479
> 
> The patch was created by Debian maintainer of the package, and is as follows
> (0001-Cleanup-existing-temporary-kernel-headers-path.patch):
> 
> --- a/src/cc/frontends/clang/kbuild_helper.cc
> +++ b/src/cc/frontends/clang/kbuild_helper.cc
> @@ -215,7 +215,8 @@
>dirpath = std::string(dirpath_tmp);
> 
>if (file_exists(dirpath_tmp))
> -return 0;
> +snprintf(dirpath_tmp, 256, "Cleaning up already existing path %s",
> dirpath_tmp);
> +system(("rm -rf " + std::string(dirpath_tmp)).c_str());
> 
>// First time so extract it
>return extract_kheaders(dirpath, uname_data);
> 
> 
> dirpath_tmp is getenv("TMPDIR") here, obvious code execution. Note that
> there's no brackets, so the system code with TMPDIR env is executed
> unconditionally.
> 
> The exploitation is as simple as that:
> 
> TMPDIR=';id;' tcpconnect-bfpcc

FWIW, there is
https://security-tracker.debian.org/tracker/CVE-2024-2314 for the
(original) issue. So I guess you could drop the Debian specific patch
addition and use the upstream fix in v0.30.0. (but have not fully
verified).

Regards,
Salvatore