Bug#1036884: 64-bit time_t: an update
Hi folks, Two months ago, I posted with a proposal for how to handle a transition to 64-bit time_t on 32-bit archs in the trixie cycle. https://lists.debian.org/debian-devel/2023/05/msg00168.html We have pretty good consensus on the path forward; however, at the time I posted I had hoped to have an archive analysis done within a month, so that this could be staged as the first major transition after trixie opened. This timeline proved to be very optimistic. The problem is that, to understand the impact that a change to the size of time_t will have on a library's ABI, it must be possible to compile the headers that expose that API; and we have a significant number of -dev packages in the archive that for one reason or another don't straightforwardly compile out of the box. The Ubuntu Foundations team have been putting in effort over the past two months, package-by-package, to figure out how to make them compile so that we know if their ABI is affected. However, despite a significant investment of effort, we still have roughly 1500 -dev packages still in need of analysis, and have sustained a rate of processing only around 50 -dev packages a week. The "good" news is that, although there are over 1500 -dev packages yet to be analyzed, we have prioritized libraries based on the number of reverse-dependencies and therefore these 1500 -dev packages have among them less than 300 reverse-build-dependencies that have not already been identified as part of the transition (800 of these -dev packages have no reverse-build-dependencies at all). Therefore, I would like to propose the following. - Assume the remaining 1500 -dev packages are affected by the ABI breakage. This will increase the number of library packages included in the transition requiring sourceful uploads from < 500 to 2000[1], but will only increase the number of packages requiring rebuilds from 5300 to 5600. - Agree a target window together with the Release Team for when the transition will be uploaded to unstable; and based on this, set a deadline beforehand for finalizing the list of library packages whose binary package names will be changed. - We in Ubuntu Foundations will continue on a best effort basis to drive down the list of -dev packages which cannot be analyzed, until that deadline. - Any party (maintainer or otherwise) interested in having some of these library packages excluded from the transition is welcome to contribute fixes up to that deadline that will let us analyze them and show that the ABI has not changed. Your thoughts? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] All numbers approximate: the analysis that has been completed so far has been done against Ubuntu lunar as a stable reference base. The Debian transition will of course be done based on a complete analysis of unstable, which is in progress separately. libgnome-rr-4-dev libhfsp-dev libhx-dev libibnetdisc-dev libip6tc-dev libipmiconsole-dev libipset-dev libisns-dev libisoburn-dev libixion-dev libjpeg-turbo8-dev libklibc-dev libkrad-dev libksba-dev liblasso3-dev libldacbt-abr-dev libldb-dev liblouisutdml-dev liblrm2-dev libmaa-dev libmircommon-dev libmiroil-dev libmirplatform-dev libmirwayland-dev libmlir-14-dev libmozjs-102-dev libmutter-11-dev libnetplan-dev libntirpc-dev libnutscan-dev liborcus-dev libotf-dev libpils2-dev libportal-dev libpskc-dev libptexenc-dev libpython3.10-dev libpython3.11-dev libradosstriper-dev libreoffice-dev libsource-highlight-dev libsss-certmap-dev libsss-simpleifp-dev libstdc++-11-dev libstdc++-12-dev libstonith1-dev libsysmetrics-dev libtotem-dev libunwind-14-dev libunwind-15-dev libusbredirhost-dev libuwac0-dev libverto-dev libvolume-key-dev libwhoopsie-dev libwhoopsie-preferences-dev lua-rrd-dev python3-ldb-dev python3-talloc-dev rhythmbox-dev ruby3.0-dev ruby3.1-dev samba-dev slapi-dev libblimps3-dev libfishcamp-dev libopenvr-dev libparmetis-dev libtestu01-0-dev libttspico-dev 389-ds-base-dev android-libandroidfw-dev android-libselinux-dev android-libsepol-dev android-libunwind-dev angelscript-dev atfs-dev cairo-dock-dev casacore-dev cauchy-dev codeblocks-dev coinor-libbonmin-dev coinor-libcbc-dev libfprint-2-tod-dev dovecot-dev irssi-dev isc-dhcp-dev libaal-dev libapache2-mod-perl2-dev bind9-dev libcanberra-gtk-common-dev libclc-14-dev libclc-15-dev libd3dadapter9-mesa-dev libdpkg-dev libfreeradius-dev libglvnd-core-dev libmirrenderer-dev libpinyin-common-dev libpolly-15-dev libradospp-dev libreiser4-dev libreofficekit-dev libubi-dev mir-renderer-gl-dev ocfs2-tools-dev php8.1-dev rados-objclass-dev remmina-dev zsh-dev libamgcl-dev libjulius-dev libthrust-dev notion-dev ableton-link-dev android-libbase-dev android-libcutils-dev
Bug#1041498: bookworm-pu: package testng7/7.5-2~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: test...@packages.debian.org, d...@debian.org, vladimir.pe...@canonical.com Control: affects -1 + src:testng7 We need to introduce a backport of testng7 in the version found in trixie to bookworm (and TBD, also for bullseye). It's needed for the latest versions of openjdk-17 LTS (as part of the test suite). The debdiff below is against the version of testng7 in trixie (since the package is new in bookworm). Cheers, Moritz diff -Nru testng7-7.5/debian/changelog testng7-7.5/debian/changelog --- testng7-7.5/debian/changelog2023-06-15 20:21:39.0 +0200 +++ testng7-7.5/debian/changelog2023-07-19 21:03:12.0 +0200 @@ -1,3 +1,9 @@ +testng7 (7.5-2~deb12u1) bookworm; urgency=medium + + * Build for Bookworm, needed by latest OpenJDK 17 LTS releases + + -- Moritz Mühlenhoff Wed, 19 Jul 2023 21:03:12 +0200 + testng7 (7.5-2) unstable; urgency=medium * Source-only upload.
Processed: bookworm-pu: package testng7/7.5-2~deb12u1
Processing control commands: > affects -1 + src:testng7 Bug #1041498 [release.debian.org] bookworm-pu: package testng7/7.5-2~deb12u1 Added indication that 1041498 affects src:testng7 -- 1041498: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041498 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1041348: RM: https-everywhere/stable -- ROM; obsolete;major browsers offer native support now;
Control: tags -1 - moreinfo On Wed, 2023-07-19 at 03:28 +0200, Markus Koschany wrote: > I have uploaded a new revision of boxer-data and debian-parl to > Bookworm now. > This update removes the dependency on webext-https-everywhere. Jonas > agreed to > this change. > > https://bugs.debian.org/1041350 > > AFAIK nothing else should prevent the removal of https-everywhere > from > Bookworm. > Thanks. Untagging so this gets back on the radar for 12.2. Regards, Adam
Processed: Re: Bug#1041348: RM: https-everywhere/stable -- ROM; obsolete;major browsers offer native support now;
Processing control commands: > tags -1 - moreinfo Bug #1041348 [release.debian.org] RM: https-everywhere -- ROM; obsolete;major browsers offer native support now Removed tag(s) moreinfo. -- 1041348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041348 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1006551: marked as done (bullseye-pu: package tiff/4.2.0-1+deb11u1)
Your message dated Wed, 19 Jul 2023 18:13:24 +0100 with message-id <6532a164f2f72c66a8f64e39ac37db994fcb9281.ca...@adam-barratt.org.uk> and subject line Re: Bug#1006551: bullseye-pu: package tiff/4.2.0-1+deb11u1 has caused the Debian Bug report #1006551, regarding bullseye-pu: package tiff/4.2.0-1+deb11u1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1006551: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006551 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org User: release.debian@packages.debian.org Tags: bullseye Severity: normal Hi RMs, A security update of tiff for issues not warrant a DSA but still would be good to have fixed. Work done by Thorsten Alteholz that I've double checked. Debdiff is attached. Thanks for consideration, Laszlo/GCS diff -Nru tiff-4.2.0/debian/changelog tiff-4.2.0/debian/changelog --- tiff-4.2.0/debian/changelog 2020-12-21 15:06:46.0 +0100 +++ tiff-4.2.0/debian/changelog 2022-02-27 17:02:02.0 +0100 @@ -1,3 +1,20 @@ +tiff (4.2.0-1+deb11u1) bullseye; urgency=high + + [ Thorsten Alteholz ] + * CVE-2022-22844 +out-of-bounds read in _TIFFmemcpy in certain situations involving a +custom tag and 0x0200 as the second word of the DE field. + * CVE-2022-0562 +Null source pointer passed as an argument to memcpy() function within +TIFFReadDirectory(). This could result in a Denial of Service via +crafted TIFF files. + * CVE-2022-0561 +Null source pointer passed as an argument to memcpy() function within +TIFFFetchStripThing(). This could result in a Denial of Service via +crafted TIFF files. + + -- Laszlo Boszormenyi (GCS) Sun, 27 Feb 2022 17:02:02 +0100 + tiff (4.2.0-1) unstable; urgency=medium * New upstream release. diff -Nru tiff-4.2.0/debian/patches/CVE-2022-0561.patch tiff-4.2.0/debian/patches/CVE-2022-0561.patch --- tiff-4.2.0/debian/patches/CVE-2022-0561.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.2.0/debian/patches/CVE-2022-0561.patch 2022-02-27 16:57:51.0 +0100 @@ -0,0 +1,26 @@ +From eecb0712f4c3a5b449f70c57988260a667ddbdef Mon Sep 17 00:00:00 2001 +From: Even Rouault +Date: Sun, 6 Feb 2022 13:08:38 +0100 +Subject: [PATCH] TIFFFetchStripThing(): avoid calling memcpy() with a null + source pointer and size of zero (fixes #362) + +--- + libtiff/tif_dirread.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +Index: tiff-4.2.0/libtiff/tif_dirread.c +=== +--- tiff-4.2.0.orig/libtiff/tif_dirread.c 2022-02-22 23:56:43.727328819 +0100 tiff-4.2.0/libtiff/tif_dirread.c 2022-02-22 23:56:43.727328819 +0100 +@@ -5765,8 +5765,9 @@ + _TIFFfree(data); + return(0); + } +-_TIFFmemcpy(resizeddata,data,(uint32)dir->tdir_count*sizeof(uint64)); +-_TIFFmemset(resizeddata+(uint32)dir->tdir_count,0,(nstrips-(uint32)dir->tdir_count)*sizeof(uint64)); ++if( dir->tdir_count ) ++_TIFFmemcpy(resizeddata,data, (uint32)dir->tdir_count * sizeof(uint64)); ++_TIFFmemset(resizeddata+(uint32)dir->tdir_count, 0, (nstrips - (uint32)dir->tdir_count) * sizeof(uint64)); + _TIFFfree(data); + data=resizeddata; + } diff -Nru tiff-4.2.0/debian/patches/CVE-2022-0562.patch tiff-4.2.0/debian/patches/CVE-2022-0562.patch --- tiff-4.2.0/debian/patches/CVE-2022-0562.patch 1970-01-01 01:00:00.0 +0100 +++ tiff-4.2.0/debian/patches/CVE-2022-0562.patch 2022-02-27 16:57:51.0 +0100 @@ -0,0 +1,24 @@ +From 561599c99f987dc32ae110370cfdd7df7975586b Mon Sep 17 00:00:00 2001 +From: Even Rouault +Date: Sat, 5 Feb 2022 20:36:41 +0100 +Subject: [PATCH] TIFFReadDirectory(): avoid calling memcpy() with a null + source pointer and size of zero (fixes #362) + +--- + libtiff/tif_dirread.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +Index: tiff-4.2.0/libtiff/tif_dirread.c +=== +--- tiff-4.2.0.orig/libtiff/tif_dirread.c 2022-02-22 23:56:49.919326843 +0100 tiff-4.2.0/libtiff/tif_dirread.c 2022-02-22 23:56:49.915326845 +0100 +@@ -4173,7 +4173,8 @@ + goto bad; + } + +-memcpy(new_sampleinfo, tif->tif_dir.td_sampleinfo, old_extrasamples * sizeof(uint16)); ++if (old_extrasamples > 0) ++memcpy(new_sampleinfo, tif->tif_dir.td_sampleinfo, old_extrasamples * sizeof(uint16)); + _TIFFsetShortArray(>tif_dir.td_sampleinfo, new_sampleinfo,
NEW changes in stable-new
Processing changes file: debian-installer-netboot-images_20230607+deb12u1_all-buildd.changes ACCEPT
Bug#1041227: transition: suitesparse
On 2023-07-19 13:37:44 +0200, Sébastien Villemot wrote: > Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit : > > On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote: > > > Please schedule a transition for suitesparse 7, which currently sits in > > > experimental. > > > > Please go ahead. > > Thanks for driving this transition so far. > > I have noticed the build failures of octave on 32-bit architectures > (that you reported in #1041460). > > Actually, it turns out that suitesparse 7 is partly broken on 32-bit > architectures. Contrarily to what I said previously, there is an ABI > change on 32-bit architectures. And due to the way that this ABI change > was performed, it had the unintended consequence of breaking libspqr3 > (provided by src:suitesparse) on 32-bit architectures. Upstream > realized this too late (and did not make much publicity around it, so I > was not aware of the issue before starting the transition). > > Upstream seems to be working on a fix, but at this point there is none > available. The only affected package seems to be octave, for which > there is a workaround (disabling libspqr use on 32-bit archs, which > implies that some functionalities won’t be available there). I hope > this situation is only temporary. Let's try this workaround until upstream has the fix ready. Cheers -- Sebastian Ramacher
Bug#1041227: transition: suitesparse
Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit : > On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote: > > Please schedule a transition for suitesparse 7, which currently sits in > > experimental. > > Please go ahead. Thanks for driving this transition so far. I have noticed the build failures of octave on 32-bit architectures (that you reported in #1041460). Actually, it turns out that suitesparse 7 is partly broken on 32-bit architectures. Contrarily to what I said previously, there is an ABI change on 32-bit architectures. And due to the way that this ABI change was performed, it had the unintended consequence of breaking libspqr3 (provided by src:suitesparse) on 32-bit architectures. Upstream realized this too late (and did not make much publicity around it, so I was not aware of the issue before starting the transition). Upstream seems to be working on a fix, but at this point there is none available. The only affected package seems to be octave, for which there is a workaround (disabling libspqr use on 32-bit archs, which implies that some functionalities won’t be available there). I hope this situation is only temporary. There are two other reverse dependencies of libspqr (petsc and apbs) but so far they don’t seem to be affected (they probably are to some extent, but at least no FTBFS or autopkgtest failure in sight). Ideally I should have waited longer before starting this transition but it’s now too late (unless you think that the transition should be rolled back, though that seems a bit extreme given the limited extent of the breakage; in particular, 32-bit archs are probably not used that much for number crunching these days). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041475: bullseye-pu: package hnswlib/0.4.0-3+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hnsw...@packages.debian.org
Control: affects -1 + src:hnswlib
Hi,
[ Reason ]
hnswlib is affected by CVE-2023-37365 marked no-dsa, documented
through the important bug #1041426. Quoting the CVE for short:
hnswlib has a double free in init_index when the M argument is a
large integer.
[ Impact ]
Users of hnswlib may encounter double-free crashes when
specifying randomly the M parameters to the software.
[ Tests ]
I verified the package built in a clean bullseye chroot, then
verified there were no autopkgtest regressions in bullseye, then
verified manualy that the reproducer did trigger the crash with
the current version in bullseye, and finally that the patched
version did not trigger the crash anymore, but instead raised
the warning message appropriately.
[ Risks ]
There is little risk as the change is relatively straightforward
but users who might like to set off-specifications values of the
M parameter may run into the self imposed limitation. M is
documented to have values that make sense in a range from 2 to
100, and the patch sets a hard limit at 1 per upstream
recommendation.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in oldstable
[*] the issue is verified as fixed in unstable
[ Changes ]
Changes mostly consists in applying a version of the patch
discussed with upstream[1] ported to hnswlib 0.4.0-3 in
bullseye. Instead of forwarding the value of the argument M
as-is, the code now checks for the value to be lesser than 1
before applying. If the value is larger, then it is capped and
the library issues a warning.
[1]: https://github.com/nmslib/hnswlib/pull/484
[ Other info ]
It might have made sense to also set a check for M == 1, as it
will result in a crash, probably not as serious as the double
free though:
Traceback (most recent call last):
File "", line 1, in
RuntimeError: Not enough memory: addPoint failed to allocate linklist
M == 0 looks to behave, or has a special meaning. In doubt, I
prefer leaving as-is.
I didn't notice lintian errors about the bullseye distribution,
contrary to the bookworm side.
Have a nice day, :)
--
.''`. Étienne Mollier
: :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/4, please excuse my verbosity
`-on air: Mile Marker Zero - Reaping Tide
diff -Nru hnswlib-0.4.0/debian/changelog hnswlib-0.4.0/debian/changelog
--- hnswlib-0.4.0/debian/changelog 2020-11-10 23:06:36.0 +0100
+++ hnswlib-0.4.0/debian/changelog 2023-07-19 11:07:28.0 +0200
@@ -1,3 +1,12 @@
+hnswlib (0.4.0-3+deb11u1) bullseye; urgency=medium
+
+ * Team upload.
+ * cve-2023-37365.patch: new: fix CVE-2023-37365.
+This is done by capping M to 1 per discussion with upstream.
+(Closes: #1041426)
+
+ -- Étienne Mollier Wed, 19 Jul 2023 11:07:28 +0200
+
hnswlib (0.4.0-3) unstable; urgency=medium
* Team Upload.
diff -Nru hnswlib-0.4.0/debian/patches/cve-2023-37365.patch
hnswlib-0.4.0/debian/patches/cve-2023-37365.patch
--- hnswlib-0.4.0/debian/patches/cve-2023-37365.patch 1970-01-01
01:00:00.0 +0100
+++ hnswlib-0.4.0/debian/patches/cve-2023-37365.patch 2023-07-19
11:04:35.0 +0200
@@ -0,0 +1,40 @@
+Description: hnswalg.h: cap M to 1 (CVE-2023-37365)
+ This patch works around issue nmslib#467, also referenced as CVE-2023-37365,
+ by implementing Yury Malkov's suggestion about capping the M value,
+ coding the maximum number of outgoing connections in the graph, to a
+ reasonable enough value of the order of 1. For the record, the
+ documentation indicates reasonable values for M range from 2 to 100,
+ which are well within the cap; see ALGO_PARAMS.md.
+ .
+ The reproducer shown in issue nmslib#467 doesn't trigger the double free
+ condition anymore after this change is applied, but completes
+ successfully, although with the below warning popping up on purpose:
+ .
+ warning: M parameter exceeds 1 which may lead to adverse effects.
+ Cap to 1 will be applied for the rest of the processing.
+
+Author: Étienne Mollier
+Bug: https://github.com/nmslib/hnswlib/issues/467
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041426
+Forwarded: https://github.com/nmslib/hnswlib/pull/484
+Reviewed-by: Yury Malkov
+Last-Update: 2023-07-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- hnswlib.orig/hnswlib/hnswalg.h
hnswlib/hnswlib/hnswalg.h
+@@ -34,7 +34,13 @@
+ data_size_ = s->get_data_size();
+ fstdistfunc_ = s->get_dist_func();
+ dist_func_param_ = s->get_dist_func_param();
+-M_ = M;
++if ( M <= 1 ) {
++M_ = M;
++} else {
++
Processed: bullseye-pu: package hnswlib/0.4.0-3+deb11u1
Processing control commands: > affects -1 + src:hnswlib Bug #1041475 [release.debian.org] bullseye-pu: package hnswlib/0.4.0-3+deb11u1 Added indication that 1041475 affects src:hnswlib -- 1041475: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041475 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1041468: bookworm-pu: package hnswlib/0.6.2-2+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: hnsw...@packages.debian.org Control: affects -1 + src:hnswlib Hi Stable Release Managers, [ Reason ] hnswlib is affected by CVE-2023-37365 marked no-dsa, documented through the important bug #1041426. Quoting the CVE for short: hnswlib has a double free in init_index when the M argument is a large integer. [ Impact ] Users of hnswlib may encounter double-free crashes when specifying randomly the M parameters to the software. [ Tests ] I verified the package built in a clean bookworm chroot, then verified there were no autopkgtest regressions in bookworm, then verified manualy that the reproducer did trigger the crash with the current version in bookworm, and finally that the patched version did not trigger the crash anymore, but instead raised the warning message appropriately. [ Risks ] There is little risk as the change is relatively straightforward but users who might like to set off-specifications values of the M parameter may run into the self imposed limitation. M is documented to have values that make sense in a range from 2 to 100, and the patch sets a hard limit at 1 per upstream recommendation. [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in stable [*] the issue is verified as fixed in unstable [ Changes ] Changes mostly consists in applying a version of the patch discussed with upstream[1] ported to hnswlib 0.6.2-2 in bookworm. Instead of forwarding the value of the argument M as-is, the code now checks for the value to be lesser than 1 before applying. If the value is larger, then it is capped and the library issues a warning. [1]: https://github.com/nmslib/hnswlib/pull/484 [ Other info ] It might have made sense to also set a check for M == 1, as it will result in a crash, probably not as serious as the double free though: Traceback (most recent call last): File "", line 1, in RuntimeError: Not enough memory: addPoint failed to allocate linklist M == 0 looks to behave, or has a special meaning. In doubt, I prefer leaving as-is. Last info, lintian loudly complained at the distribution field, but looking at the Developer Reference, the field seemed good, so if there is anything I need to change, don't hesitate to tell: E: hnswlib changes: bad-distribution-in-changes-file bookworm Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/4, please excuse my verbosity `-on air: Chroma Key - Human Love diff -Nru hnswlib-0.6.2/debian/changelog hnswlib-0.6.2/debian/changelog --- hnswlib-0.6.2/debian/changelog 2022-10-12 16:11:36.0 +0200 +++ hnswlib-0.6.2/debian/changelog 2023-07-19 10:27:07.0 +0200 @@ -1,3 +1,12 @@ +hnswlib (0.6.2-2+deb12u1) bookworm; urgency=medium + + * Team upload. + * cve-2023-37365.patch: new: fix CVE-2023-37365. +This is done by capping M to 1 per discussion with upstream. +(Closes: #1041426) + + -- Étienne Mollier Wed, 19 Jul 2023 10:27:07 +0200 + hnswlib (0.6.2-2) unstable; urgency=medium * Team upload. diff -Nru hnswlib-0.6.2/debian/patches/cve-2023-37365.patch hnswlib-0.6.2/debian/patches/cve-2023-37365.patch --- hnswlib-0.6.2/debian/patches/cve-2023-37365.patch 1970-01-01 01:00:00.0 +0100 +++ hnswlib-0.6.2/debian/patches/cve-2023-37365.patch 2023-07-19 10:24:55.0 +0200 @@ -0,0 +1,40 @@ +Description: hnswalg.h: cap M to 1 (CVE-2023-37365) + This patch works around issue nmslib#467, also referenced as CVE-2023-37365, + by implementing Yury Malkov's suggestion about capping the M value, + coding the maximum number of outgoing connections in the graph, to a + reasonable enough value of the order of 1. For the record, the + documentation indicates reasonable values for M range from 2 to 100, + which are well within the cap; see ALGO_PARAMS.md. + . + The reproducer shown in issue nmslib#467 doesn't trigger the double free + condition anymore after this change is applied, but completes + successfully, although with the below warning popping up on purpose: + . + warning: M parameter exceeds 1 which may lead to adverse effects. + Cap to 1 will be applied for the rest of the processing. + +Author: Étienne Mollier +Bug: https://github.com/nmslib/hnswlib/issues/467 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041426 +Forwarded: https://github.com/nmslib/hnswlib/pull/484 +Reviewed-by: Yury Malkov +Last-Update: 2023-07-19 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- hnswlib.orig/hnswlib/hnswalg.h hnswlib/hnswlib/hnswalg.h +@@ -33,7 +33,13 @@ + data_size_ = s->get_data_size(); + fstdistfunc_ = s->get_dist_func(); +
Processed: bookworm-pu: package hnswlib/0.6.2-2+deb12u1
Processing control commands: > affects -1 + src:hnswlib Bug #1041468 [release.debian.org] bookworm-pu: package hnswlib/0.6.2-2+deb12u1 Added indication that 1041468 affects src:hnswlib -- 1041468: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041468 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1006551: bullseye-pu: package tiff/4.2.0-1+deb11u1
Hi SRMs, I think this can be closed since tiff already has the deb11u4 version in bullseye through a previous security update. Regards, Aron
NEW changes in stable-new
Processing changes file: debian-installer-netboot-images_20230607+deb12u1_source.changes ACCEPT
