Re: New proposed-updates diff: libapache2-mod-rivet 3.2.1-1
My mistake. My sponsor corrected the problem and re-uploaded to unstable as 3.2.1-2. Still there is a p-u-new reference to the 3.2.1-1 package in https://release.debian.org/proposed-updates/stable.html. Am I supposed to take some action to correct this? -- Massimo On 11/13/21 9:18 PM, Adam D. Barratt wrote: Hi, On Sat, 2021-11-13 at 20:03 +, Debian Queue Viewer wrote: Version in base suite: 3.2.0-1 Base version: libapache2-mod-rivet_3.2.0-1 Target version: libapache2-mod-rivet_3.2.1-1 +libapache2-mod-rivet (3.2.1-1) stable; urgency=medium + + * New upstream release. + * New rivet version addresses issue with multiple AM_AUTOMAKE_INIT +expansion (Closes: #998490). + * Correcting the name of the target directory where rivet library and +Tcl scripts are moved into (it still had the old 3.1 version name) I'm assuming that you intended to upload this to unstable, not stable. If targetting stable was actually intentional, then I'm afraid that you need to fix the issue in unstable before we can consider accepting it for stable. Any upload to stable should also be accompanied by a "p-u" bug filed against release.debian.org, which would need to explain why a larger release should be accepted, rather than a smaller targetted fix. Regards, Adam Firma il tuo 5x1000 all’Università di Parma, aiutaci a essere sempre più accoglienti e inclusivi verso le nostre studentesse e i nostri studenti - Indica 00308780345 nella tua denuncia dei redditi.
Re: New proposed-updates diff: libapache2-mod-rivet 3.2.1-1
On Sat, Nov 13, 2021 at 08:27:39PM +, Adam D. Barratt wrote: > Hi, > > On Sat, 2021-11-13 at 20:03 +, Debian Queue Viewer wrote: > > Version in base suite: 3.2.0-1 > > > > Base version: libapache2-mod-rivet_3.2.0-1 > > Target version: libapache2-mod-rivet_3.2.1-1 > > +libapache2-mod-rivet (3.2.1-1) stable; urgency=medium > + > + * New upstream release. > + * New rivet version addresses issue with multiple AM_AUTOMAKE_INIT > +expansion (Closes: #998490). > + * Correcting the name of the target directory where rivet library and > +Tcl scripts are moved into (it still had the old 3.1 version name) > > I'm assuming that you intended to upload this to unstable, not stable. > If targetting stable was actually intentional, then I'm afraid that you > need to fix the issue in unstable before we can consider accepting it > for stable. Hello Adam, yes that was intended to be uploaded to unstable, I missed the issue and I screwed that up as the sponsor. Please remove the package from the queue. Sorry for the noise. Regards, Sven signature.asc Description: PGP signature
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
[ Reason ]
- - Low-severity security issue when receiving SONMP packets.
CVE-2021-43612
- - Annoying bug where LLDP packets are encapsulated in VLAN 0 when some
configuration directives are used. Many implementations reject such
a packet (regression introduced in 1.0.6)
[ Impact ]
- - Someone could crash lldpd from another neighbor if the user enables
SONMP (quite unlikely).
- - People cannot use some configuration directives.
[ Tests ]
- - Both codes are covered by tests in upstream. The SONMP tests are run
during build as well. The VLAN 0 test is not run during build.
[ Risks ]
- - For SONMP, low risk as it is seldomly used and correctly formed
packets are part of the tests run during build.
- - For VLAN 0, the change is trivial, tested upstream and reported OK by two
users.
[ 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 ]
- - SONMP: there was a confusion about the size of a packet. The same
variable was used for the payload size and for checking the size
with Ethernet headers.
- - VLAN 0: when changing some settings, a struct containing the changed
settings is transmitted. -1 was used to say "no change" but it was
interpreted as a change.
[ Other info ]
- - Security team is OK to fix the security issue in a point release.
- - I don't think this is worth fixing the SONMP issue in Buster, but I
can do that too. The VLAN issue is not present.
-BEGIN PGP SIGNATURE-
iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGRU44SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5++gP/jK+rA7DgjxgweFrlUezPB39QSg6wcmu
9YrUO8wyjSzZ0A51Gfh/afyJAKRKehy3tD/nWvrQumn5ZkYXMhVbock5zJbgnTmo
1ndd2CtIOlpdSceqmnxX83Qt5qj7yHLWCzyAYg+ujgO1Su/IrE6GwwWr3+OBJQdN
lwLrbDzIe+Xv+4sYLLhWjO1ApVHpJmLJYYywBWug6YkTa9hx1wixPGm76G1Z4tvc
312L+9uwJqdp85Nb8w29VgBx8nDOWZS54FaimnggmGk895beQdI4wUCGfrJ/Tqkt
K4emDeOUv5pUudDYNU98a0byf7Ahif+QVZLS0w9p32uHd7qtr1ZwkmhcO2I0W0jA
EWIC7PW3qyQqa8SrD068Sx9jEhCt69uJaQyDUV38DbCmNFjip4oK607XeLuh/WwC
R6TI3iMro3T03QSzyYyFvWLJpL0n/xHtoMb0UXWY+KE38uOQQ1Fdv3JkvxxI6q6Z
8FhpTYr1ONE9uj577aMj3bX9BkxdVKKjy48bLEkHhTd1KS/FOLpWMmnlRVNBAr8t
KDn09xcsxU+anIGunFwrATqH8sBFOqO0gvr+ylgyswQiW3L8WWM2uyG1+UoO/AeW
lwMHk+6WUuejhB/7PzA0Wcv5zfgkwahZRf2zN6ohON6IaVR6Pbn0+lSYU5rlramB
dsd1jEbkXZ36
=W7Cl
-END PGP SIGNATURE-
>From d70b8be04c6d8638e6f2cd612a07e73992fa0798 Mon Sep 17 00:00:00 2001
From: Vincent Bernat
Date: Sun, 14 Nov 2021 15:42:12 +0100
Subject: [PATCH] Tentative security update for Bullseye
---
debian/changelog | 8 ++
...et-VLAN-tag-if-client-did-not-set-it.patch | 27 ++
...-overflow-when-reading-SONMP-packets.patch | 93 +++
debian/patches/series | 2 +
4 files changed, 130 insertions(+)
create mode 100644
debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
create mode 100644
debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
diff --git a/debian/changelog b/debian/changelog
index bb87d8129f9e..68ae7b91d22d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lldpd (1.0.12-1+deb11u1) bullseye; urgency=high
+
+ * d/patches: sonmp: fix heap overflow when reading SONMP packets.
+CVE-2021-43612
+ * d/patches: client: do not set VLAN tag if client did not set it
+
+ -- Vincent Bernat Sun, 14 Nov 2021 15:41:59 +0100
+
lldpd (1.0.12-1) unstable; urgency=medium
* New upstream release.
diff --git
a/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
new file mode 100644
index ..1f65986ae27e
--- /dev/null
+++
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
@@ -0,0 +1,27 @@
+From 261afbe371ab316a4bf710338f6d9183a01e083f Mon Sep 17 00:00:00 2001
+From: Vincent Bernat
+Date: Wed, 29 Sep 2021 12:02:15 +0200
+Subject: [PATCH] client: do not set VLAN tag if client did not set it
+
+This fixes a bug where frames could be tagged with VLAN 0 after client
+configuration.
+---
+ src/daemon/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/daemon/client.c b/src/daemon/client.c
+index b4a08aae80a8..0d0f3ea37a19 100644
+--- a/src/daemon/client.c
b/src/daemon/client.c
+@@ -390,7 +390,7 @@ _client_handle_set_port(struct lldpd *cfg,
+ port->p_disable_rx = port->p_disable_tx = 1;
+ break;
+ }
+- if (set->vlan_tx_enabled >= -1) {
++ if (set->vlan_tx_enabled > -1) {
+ port->p_vlan_tx_enabled = set->vlan_tx_enabled;
+ port->p_vlan_tx_tag = set->vla
Bug#999668: bullseye-pu: package jwm/2.3.7-5+deb11u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] Fix segfault when using keyboard bindings to move a window for the first time (uninitialized variable). This issue is present on jwm 2.3.7, so it affects both stable and oldstable (It also affects testing but 2.4.0 is soon gonna migrate from unstable). [ Impact ] JWM will crash and exit if the user tries to move a window using the keyboard bindings for the first time (it won't if the window gets moved by the mouse first). [ Tests ] Manually reproduced the issue and confirmed that the fix addresses it. [ Risks ] I don't think there's a risk of a regression since the fix is a oneliner, initializing the variable. [ 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 ] Backport of an upstream patch that initializes the currentClient variable. [ Other info ] https://bugs.debian.org/977878 https://github.com/joewing/jwm/issues/410 https://github.com/rdnvndr/jwm/commit/d0e28abd8eb8748470f07595be6da5cec05b4939 As per the latest instructions from the release team, I have gone ahead and uploaded the fix already. -- Samuel Henrique jwm_2.3.7-5+deb11u1.debdiff Description: Binary data
Bug#998907: closed by Håvard Flaget Aasen (Closing, CVE marked as unimportant)
Hi Håvard, On Fri, Nov 12, 2021 at 11:21:08PM +, Debian Bug Tracking System wrote: [...] > CVE-2021-40985 has now been marked as unimportant, I'm therefore > closing this bug, since the CVE was the sole purpose of the update. > > Regards, > Håvard In case this was just caused by a uncertainity what is acceptable to fix via a point release and what not: I guess SRM will accept updates in stable as well for simpler bugfixes with low severity (even more if you had already prepared the debdiff as attached to this bug and as well #998902). Regards, Salvatore
