Your message dated Fri, 19 Apr 2019 11:37:00 +0000 with message-id <b16b0557-fe87-1140-4e4f-8ea868819...@thykier.net> and subject line Re: Bug#927406: unblock: libcoap2/4.2.0-2 has caused the Debian Bug report #927406, regarding unblock: libcoap2/4.2.0-2 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.) -- 927406: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927406 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: unblock Please unblock package libcoap2 Upstream pointed me to an upstream issue after the release of version 4.2.0 a few weeks ago that might provoke a crash of a linked application due a possible null pointer dereferenced access. This is happen within the GnuTLS part of libcoap. The fix was easy, use correct pointer arithmetic and logic in the code. But the review of the attempt to fix this in the upstream project wasn't done carefully, so a second patch was needed. I applied both patches (and did not merge them together) to keep up the fixing more in sync how it happen in the upstream project. This is a debdiff between version 4.2.0-1 (testing) and 4.2.0-2 (unstable). $ cat libcoap2_4.2.0-2.debdiff diff -Nru libcoap2-4.2.0/debian/changelog libcoap2-4.2.0/debian/changelog --- libcoap2-4.2.0/debian/changelog 2019-03-02 17:35:18.000000000 +0100 +++ libcoap2-4.2.0/debian/changelog 2019-04-13 08:00:48.000000000 +0200 @@ -1,3 +1,14 @@ +libcoap2 (4.2.0-2) unstable; urgency=medium + + * [2f3b27d] rebuild patch queue from patch-queue branch + added patches (cherry-picked from upstream): + Client-crashes-in-gnutls-psk-setup.patc + Fix-321-was-not-correctly-implemented.patch + These patches fixing a possible crash in the GnuTLS bindings due a + possible null pointer dereferenced access. + + -- Carsten Schoenert <c.schoen...@t-online.de> Sat, 13 Apr 2019 08:00:48 +0200 + libcoap2 (4.2.0-1) unstable; urgency=medium * [b0fedea] New upstream version 4.2.0 diff -Nru libcoap2-4.2.0/debian/patches/Client-crashes-in-gnutls-psk-setup.patch libcoap2-4.2.0/debian/patches/Client-crashes-in-gnutls-psk-setup.patch --- libcoap2-4.2.0/debian/patches/Client-crashes-in-gnutls-psk-setup.patch 1970-01-01 01:00:00.000000000 +0100 +++ libcoap2-4.2.0/debian/patches/Client-crashes-in-gnutls-psk-setup.patch 2019-04-13 07:57:35.000000000 +0200 @@ -0,0 +1,24 @@ +From: Jon Shallow <supjps-libc...@jpshallow.com> +Date: Sun, 31 Mar 2019 20:33:46 +0100 +Subject: Client crashes in gnutls psk setup + +src/coap_gnutls.c: + +Correct typo when null terminating username. +--- + src/coap_gnutls.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/coap_gnutls.c b/src/coap_gnutls.c +index 026f378..08f3099 100644 +--- a/src/coap_gnutls.c ++++ b/src/coap_gnutls.c +@@ -404,7 +404,7 @@ psk_client_callback(gnutls_session_t g_session, + *username = gnutls_malloc(identity_len+1); + if (*username) { + memcpy(*username, identity, identity_len); +- *username[identity_len] = '\0'; ++ username[identity_len] = '\0'; + } + + key->data = gnutls_malloc(psk_len); diff -Nru libcoap2-4.2.0/debian/patches/Fix-321-was-not-correctly-implemented.patch libcoap2-4.2.0/debian/patches/Fix-321-was-not-correctly-implemented.patch --- libcoap2-4.2.0/debian/patches/Fix-321-was-not-correctly-implemented.patch 1970-01-01 01:00:00.000000000 +0100 +++ libcoap2-4.2.0/debian/patches/Fix-321-was-not-correctly-implemented.patch 2019-04-13 07:57:35.000000000 +0200 @@ -0,0 +1,26 @@ +From: Jon Shallow <supjps-libc...@jpshallow.com> +Date: Sun, 7 Apr 2019 17:48:46 +0100 +Subject: Fix #321 was not correctly implemented + +While #321 prevented a core dump, that fix still caused memory corruption. + +src/coap_gnutls.c: + +Correct the code to correctly NULL terminate the created username. +--- + src/coap_gnutls.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/coap_gnutls.c b/src/coap_gnutls.c +index 08f3099..cbfdffb 100644 +--- a/src/coap_gnutls.c ++++ b/src/coap_gnutls.c +@@ -404,7 +404,7 @@ psk_client_callback(gnutls_session_t g_session, + *username = gnutls_malloc(identity_len+1); + if (*username) { + memcpy(*username, identity, identity_len); +- username[identity_len] = '\0'; ++ (*username)[identity_len] = '\0'; + } + + key->data = gnutls_malloc(psk_len); diff -Nru libcoap2-4.2.0/debian/patches/series libcoap2-4.2.0/debian/patches/series --- libcoap2-4.2.0/debian/patches/series 2019-03-02 17:33:17.000000000 +0100 +++ libcoap2-4.2.0/debian/patches/series 2019-04-13 07:57:35.000000000 +0200 @@ -1,2 +1,4 @@ examples-Makefile.am-remove-DTLS_LIBS-variable.patch examples-Makefile.am-create-DTLS-specific-binary-names.patch +Client-crashes-in-gnutls-psk-setup.patch +Fix-321-was-not-correctly-implemented.patch unblock libcoap2/4.2.0-2 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, aarch64, arm64 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---Carsten Schoenert: > Package: release.debian.org > Severity: normal > User: release.debian....@packages.debian.org > Usertags: unblock > > Please unblock package libcoap2 > > Upstream pointed me to an upstream issue after the release of version > 4.2.0 a few weeks ago that might provoke a crash of a linked application > due a possible null pointer dereferenced access. > > This is happen within the GnuTLS part of libcoap. > > The fix was easy, use correct pointer arithmetic and logic in the code. > But the review of the attempt to fix this in the upstream project wasn't > done carefully, so a second patch was needed. > > I applied both patches (and did not merge them together) to keep up the > fixing more in sync how it happen in the upstream project. > > This is a debdiff between version 4.2.0-1 (testing) and 4.2.0-2 > (unstable). > > [...] > > unblock libcoap2/4.2.0-2 > > [...] > Unblocked, thanks. ~Niels
--- End Message ---
