Bug#912532: stunnel4: "Internal error: double free attempt" with OpenSSL 1.1.1-1 and 1.1.1-2
Dear maintainer, Another quick update: on another machine running stunnel4 3:5.49-1 as server, I tried upgrading openssl to 1.1.1-2 and then adding "options = NO_TLSv1.3" to stunnel.conf, thus forcing the two ends (both running stunnel4 3:5.49-1 and openssl 1.1.1-2) to negotiate TLS 1.2. This proves effective at preventing segfaults as well. So the problem seems to have something to do with TLS 1.3. Regards, Frank
Bug#912532: stunnel4: "Internal error: double free attempt" with OpenSSL 1.1.1-1 and 1.1.1-2
Dear maintainer, Here's some additional info I've only noticed today that might be relevant: My stunnel4 client side has OpenSSL 1.1.1-2. When the stunnel4 server side has OpenSSL 1.1.1-1 or 1.1.1-2, the two sides negotiate TLS 1.3. This is when the internal error and subsequent kernel general protection error occurs. When the stunnel4 server side downgrades to OpenSSL 1.1.1~~pre8-1, the two sides actually negotiate TLS 1.2. Hope this little detail helps to zero in on the problem. Regards, Frank
Bug#912532: stunnel4: "Internal error: double free attempt" with OpenSSL 1.1.1-1 and 1.1.1-2
Package: stunnel4 Version: 3:5.49-1 Severity: important Dear Maintainer, My stunnel4 is set up as a SOCKS VPN with configuration that is similar to <https://www.stunnel.org/socksvpn.html> My default Debian release is "testing", but in order to try TLS 1.3 early, I installed openssl 1.1.1~~pre8-1 from experimental around early August 2018. stunnel4 ran with this version of openssl just fine, negotiating TLS 1.3 with stunnel4 client + openssl 1.1.1~~pre8-1 on another host. Debian migrated openssl 1.1.1-1 to testing on 2018-10-28. Since upgrading to this version, the stunnel4 server had been failing every few hours. (The client side worked just fine though.) Typically when traffic is heavy, e.g. opening many Chrome tabs from the client side, the stunnel4 server side would fail after 20 to 30 seconds. syslog on the server reveals (I start with connection 4943 where the error occurred; stunnel4 had been running without errors until then): Oct 29 14:55:00 goo stunnel: LOG5[4943]: Service [socksSSL] accepted connection from nnn.nnn.nnn.nnn:26462 Oct 29 14:55:00 goo stunnel: LOG6[4943]: Peer certificate required Oct 29 14:55:00 goo stunnel: LOG2[4943]: INTERNAL ERROR: Double free attempt: ptr=0x7f05a801f2b0 alloc=../ssl/statem/extensions.c:949 free#1=../ssl/statem/extensions.c:948 free#2=../ssl/statem/extensions.c:948 Oct 29 14:55:00 goo stunnel: LOG6[4943]: Session id: Oct 29 14:55:00 goo stunnel: LOG6[4943]: TLS accepted: previous session reused Oct 29 14:55:00 goo stunnel: LOG6[4943]: TLSv1.3 ciphersuite: TLS_CHACHA20_POLY1305_SHA256 (256-bit encryption) Oct 29 14:55:00 goo stunnel: LOG6[4943]: Session id: Oct 29 14:55:01 goo stunnel: LOG6[4943]: SOCKS5 resolved "secure.adnxs.com" to 8 host(s) Oct 29 14:55:01 goo stunnel: LOG6[4943]: persistence: 216.58.200.4:443 not available Oct 29 14:55:01 goo stunnel: LOG6[4943]: failover: priority, starting at entry #0 Oct 29 14:55:01 goo stunnel: LOG6[4943]: s_connect: connecting 104.254.150.58:443 Oct 29 14:55:01 goo stunnel: LOG5[4943]: s_connect: connected 104.254.150.58:443 Oct 29 14:55:01 goo stunnel: LOG6[4943]: persistence: 104.254.150.58:443 cached Oct 29 14:55:01 goo stunnel: LOG5[4943]: Service [socksSSL] connected remote server from 10.240.0.4:58886 Oct 29 14:55:03 goo stunnel: LOG6[4943]: TLS closed (SSL_read) Oct 29 14:55:03 goo stunnel: LOG6[4943]: Read socket closed (readsocket) Oct 29 14:55:03 goo stunnel: LOG6[4943]: SSL_shutdown successfully sent close_notify alert Oct 29 14:55:03 goo stunnel: LOG5[4943]: Connection closed: 5651 byte(s) sent to TLS, 3003 byte(s) sent to socket (Then stunnel keeps serving 100+ connections until the kernel encounters the following.) Oct 29 14:55:18 goo kernel: [20955.029249] traps: stunnel4[7555] general protection ip:7f05c1bf6a65 sp:7f05c04d6818 error:0 in libcrypto.so.1.1[7f05c1a8a000+19f000] (At which point stunnel4 terminates.) Debian migrated openssl to 1.1.1-2 to testing on 2018-10-31. The problem persists upon upgrade to openssl 1.1.1-2. However, the problem goes away upon downgrading back to openssl 1.1.1~~pre8-1. On the face of it this looks similar to Bug #850292 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850292> which was resolved by stunnel4 3:5.39-2. Not sure if this helps. Let me know if other logs may help. Thanks for investigating. Regards, Frank Chung -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-cloud-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stunnel4 depends on: ii adduser 3.118 ii libc62.27-6 ii libssl1.11.1.1-2 ii libsystemd0 239-11 ii libwrap0 7.6.q-27 ii lsb-base 9.20170808 ii netbase 5.4 ii openssl 1.1.1-2 ii perl 5.26.2-7+b1 stunnel4 recommends no packages. Versions of packages stunnel4 suggests: pn logcheck-database -- debconf-show failed
Bug#891084: /usr/bin/slabtop: USE column reports either 100 or 0 percent only
Dear Maintainer, It appears this issue has been addressed upstream: https://gitlab.com/procps-ng/procps/commit/23ba442c886f6250d1068a82fb7d0fc544acfd63 If suitable in your opinion, please tag as fixed-upstream. Thanks. Regards, Frank
Bug#891084: /usr/bin/slabtop: USE column reports either 100 or 0 percent only
Package: procps Version: 2:3.3.12-4 Severity: normal File: /usr/bin/slabtop Dear Maintainer, It appears that slaptop is reporting USE values of 0% for any usage lower than 100%. Sample output from "slabtop -o" follows: *** sample output of slabtop -o *** Active / Total Objects (% used): 187373 / 197086 (95.1%) Active / Total Slabs (% used) : 8404 / 8404 (100.0%) Active / Total Caches (% used) : 70 / 98 (71.4%) Active / Total Size (% used) : 42760.51K / 48008.28K (89.1%) Minimum / Average / Maximum Object : 0.01K / 0.24K / 8.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 60762 60462 0%0.10K 1558 39 6232K buffer_head 30660 29695 0%0.19K 1460 21 5840K dentry 13856 10180 0%0.94K 17328 13856K xfs_inode 12064 12013 0%0.59K928 13 7424K inode_cache 12032 12032 100%0.02K 47 256 188K kmalloc-16 10980 10980 100%0.13K366 30 1464K kernfs_node_cache 6480 3680 0%0.16K270 24 1080K xfs_ili 5016 5016 100%0.20K264 19 1056K vm_area_struct 4992 4992 100%0.03K 39 128 156K kmalloc-32 4480 4480 100%0.06K 70 64 280K pid 4228 4177 0%0.57K302 14 2416K radix_tree_node 3584 3584 100%0.01K 7 51228K kmalloc-8 3060 3060 100%0.05K 36 85 144K ftrace_event_field 2816 2709 0%0.06K 44 64 176K kmalloc-64 2576 2576 100%0.09K 56 46 224K anon_vma 1792 1512 0%0.12K 56 32 224K kmalloc-128 *** end of sample output *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-cloud-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.51 ii libc62.26-6 ii libncurses5 6.1-1 ii libncursesw5 6.1-1 ii libprocps6 2:3.3.12-4 ii libtinfo56.1-1 ii lsb-base 9.20170808 Versions of packages procps recommends: ii psmisc 23.1-1 procps suggests no packages. -- no debconf information Regards, Frank Chung
Bug#681426: syslinux-themes-debian-wheezy: patches for *.cfg
tags 681426 + patch thanks Dear maintainers, The same problem affects all of /usr/share/syslinux/themes/debian-wheezy/extlinux/*.cfg. Enclosed please find patches for each. Thanks, Frank --- menu.cfg~ 2012-06-27 22:08:18.0 +0800 +++ menu.cfg2012-06-27 22:08:18.0 +0800 @@ -2,16 +2,16 @@ menu width 82 menu title Boot menu -include themes/debian-squeeze/stdmenu.cfg +include themes/debian-wheezy/stdmenu.cfg include linux.cfg include memdisk.cfg include os-prober.cfg menu separator menu begin other menu title Other options - include themes/debian-squeeze/stdmenu.cfg + include themes/debian-wheezy/stdmenu.cfg label mainmenu menu label ^Back.. menu exit - include themes/debian-squeeze/other.cfg + include themes/debian-wheezy/other.cfg menu end --- other.cfg~ 2012-06-27 22:08:18.0 +0800 +++ other.cfg 2012-06-27 22:08:18.0 +0800 @@ -1,13 +1,13 @@ label hdt menu label ^Hardware Detection Tool (HDT) - kernel themes/debian-squeeze/hdt.c32 + kernel themes/debian-wheezy/hdt.c32 text help HDT displays low-level information about the systems hardware. endtext label memtest menu label ^Memory Failure Detection (memtest86+) - linux themes/debian-squeeze/memtest.bin + linux themes/debian-wheezy/memtest.bin text help memtest86+ detects memory hardware failures. endtext --- stdmenu.cfg~2012-06-27 22:08:18.0 +0800 +++ stdmenu.cfg 2012-06-27 22:08:18.0 +0800 @@ -1,4 +1,4 @@ -menu background themes/debian-squeeze/splash.png +menu background themes/debian-wheezy/splash.png menu color title * # * menu color border * # # none menu color sel * # #76a1d0ff * --- theme.cfg~ 2012-06-27 22:08:18.0 +0800 +++ theme.cfg 2012-06-27 22:08:18.0 +0800 @@ -1,4 +1,4 @@ -include themes/debian-squeeze/menu.cfg -default themes/debian-squeeze/vesamenu.c32 +include themes/debian-wheezy/menu.cfg +default themes/debian-wheezy/vesamenu.c32 prompt 0 timeout 50
Bug#647429: [Pkg-samba-maint] Bug#647429: libpam-smbpass: prerm is not multiarch-safe
On 25 June 2012 02:29, Ivo De Decker ivo.dedec...@ugent.be wrote: tags 647429 help tags 647430 help thanks On Mon, May 28, 2012 at 04:16:35PM +0200, Jakub Wilk wrote: Jakub, Do you have an example of a package that does 'the right thing'? No, sorry. What should the package do? The manpage of pam-auth-update says that pam-auth-update --remove should be called before removing the module, but this isn't correct if the module remains for another architecture. Should pam-auth-update be made multiarch-aware and handle this automatically? If binaries from multiple architectures call pam on the same system, and a pam-module is installed for one of these architectures, but not for the other one, the pam configuration cannot be correct for both of them. Unfortunately, I have no idea what a proper fix would like either. Are these issues documented somewhere? I'm not aware of such documentation. I tried to bring up this topic on debian-devel once, but there were no answers: http://lists.debian.org/2012025057.ga8...@jwilk.net As I don't know what the proper fix for this bug should be, I'm tagging it 'help'. Same thing for #647430, which is the same bug, but for libpam-winbind. Cheers, Ivo From a naive reading of the Debian Policy Manual (Section 8.2: shared library support files, http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-support-files) and Debian Wiki's multi-arch conversion HOWTO (Section: Multi-arch: foreign support packages, http://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages), it appears that the correct solution would be: 1. Split libpam-winbind into 2 packages (likewise for libpam-smbpass); 2. One package contains files under /lib/* ; 3. The other (libpam-winbind-data?) contains support files under /usr/share/* ; 4. The support files package is made Multi-Arch: foreign; 5. The prerm action should be done in the support files package, so that it is done only once, no matter how many co-installations of libpam-winbind there are. I must confess that I'm not a regular Debian contributor, just a grateful user of libpam-winbind who would like to help out (thanks maintainers!). There may be perfectly good reasons why libpam-winbind (and libpam-smbpass) is currently one package that I'm ignorant of. Regards, Frank
Bug#683415: php5-fpm: Please rotate /var/log/php5-fpm.log
Package: php5-fpm
Version: 5.4.4-2
Severity: serious
Justification: Policy 10.8
Dear Maintainer,
Please rotate the log file /var/log/php5-fpm.log. The
/etc/init.d/php5-fpm script already has the reopen-logs action, so
something like this in /etc/logrotate.d/php5-fpm will do:
/var/log/php5-fpm.log {
rotate 12
weekly
missingok
notifempty
compress
delaycompress
postrotate
invoke-rc.d php5-fpm reopen-logs /dev/null
endscript
}
Thanks,
Frank
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.4-trunk-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages php5-fpm depends on:
ii dpkg 1.16.4.3
ii libbz2-1.01.0.6-3
ii libc6 2.13-33
ii libcomerr21.42.4-3
ii libdb5.1 5.1.29-5
ii libgssapi-krb5-2 1.10.1+dfsg-1
ii libk5crypto3 1.10.1+dfsg-1
ii libkrb5-3 1.10.1+dfsg-1
ii libmagic1 5.11-2
ii libonig2 5.9.1-1
ii libpcre3 1:8.30-5
ii libqdbm14 1.8.78-2
ii libssl1.0.0 1.0.1c-3
ii libxml2 2.8.0+dfsg1-4
ii mime-support 3.52-1
ii php5-common 5.4.4-2
ii tzdata2012c-1
ii ucf 3.0025+nmu3
ii zlib1g1:1.2.7.dfsg-13
php5-fpm recommends no packages.
Versions of packages php5-fpm suggests:
pn php-pear none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680464: openntpd: Please consider allowing NTP servers with negative delay if local clock has coarse resolution
Package: openntpd
Version: 20080406p-4
Severity: wishlist
Dear Maintainer,
I am getting negative delay syslog messages for NTP servers that are
nearby. For servers that are further away, things work normally.
Here is a syslog excerpt:
Jul 5 23:46:36 grif ntpd[5407]: peer 59.106.180.168 now valid
Jul 5 23:49:00 grif ntpd[5407]: peer 140.109.1.10 now invalid
Jul 5 23:53:47 grif ntpd[5407]: reply from 137.189.4.10: negative delay
-0.000106s, next query 3039s
Jul 6 00:12:05 grif ntpd[5407]: peer 59.124.196.84 now valid
Jul 6 00:21:19 grif ntpd[5407]: peer 59.124.196.84 now invalid
Jul 6 00:31:31 grif ntpd[5407]: reply from 118.143.17.82: negative delay
-0.90s, next query 3213s
Jul 6 00:40:42 grif ntpd[5407]: peer 140.109.1.10 now valid
Jul 6 00:44:25 grif ntpd[5407]: reply from 137.189.4.10: negative delay
-0.000137s, next query 3274s
Jul 6 01:13:58 grif ntpd[5407]: peer 59.124.196.84 now valid
Jul 6 01:25:33 grif ntpd[5407]: reply from 118.143.17.82: negative delay
-0.000109s, next query 3145s
(137.189.4.10 and 118.143.17.82 are both close to me, ping-time-wise.)
I think I have tracked down the problem as follows:
When the client's clock has coarse resolution, e.g. when clocksource is
jiffies (giving 4ms clock ticks when CONFIG_HZ=250), and the NTP server
has very good ping time to the client, it is not uncommon to have received a
response from the server before the client gets a clock tick.
In such cases, T4 == T1, so the delay calculated by (T4 - T1) - (T3 - T2)
will always be negative.
Ironically, this only happens for servers that are close by, i.e.
theoretically better for the client. If the ping time to the server is
sufficiently large, say more than 4ms, the client's clock will have a chance
to tick before getting the server's response, thus T4 T1, and so delay
calculation works as intended.
My host is a Xen HVM guest. If I boot with clocksource=acpi_pm or
clocksource=tsc, the problem with negative delay goes away, but instead the
clock keeps gaining time and NTP can't keep it in sync. So I'm pretty much
stuck with clocksource=jiffies. This probably holds true for other HVM
virtualized environments too.
Is it feasible in client.c to check for the case where T4 == T1, and if so,
assume the delay is 0? This appears to be what the NTP project does in
ntpdate.c:
ntpdate.c line 866:
/*
* Calculate the round trip delay (di) and the clock offset (ci).
* We use the equations (reordered from those in the spec):
*
* d = (t2 - t3) - (t1 - t0)
* c = ((t2 - t3) + (t1 - t0)) / 2
*/
t10 = server-org; /* pkt.xmt == t1 */
L_SUB(t10, rbufp-recv_time); /* recv_time == t0*/
t23 = rec; /* pkt.rec == t2 */
L_SUB(t23, org); /* pkt-org == t3 */
.
.
.
ntpdate.c line 890:
/*
* Calculate di in t23 in full precision, then truncate
* to an s_fp.
*/
L_SUB(t23, t10);
di = LFPTOFP(t23);
if (debug 3)
printf(offset: %s, delay %s\n, lfptoa(ci, 6), fptoa(di,
5));
di += (FP_SECOND (-(int)NTPDATE_PRECISION))
+ (FP_SECOND (-(int)server-precision)) + NTP_MAXSKW;
if (di = 0) { /* value still too raunchy to use? */
L_CLR(ci);
di = 0;
} else {
di = max(di, NTP_MINDIST);
}
Thanks!
Regards,
Frank Chung
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages openntpd depends on:
ii adduser 3.113+nmu3
ii libc62.13-33
ii libssl1.0.0 1.0.1c-3
ii netbase 5.0
openntpd recommends no packages.
openntpd suggests no packages.
-- Configuration Files:
/etc/openntpd/ntpd.conf changed:
servers time.hko.hk
servers clock.cuhk.edu.hk
servers asia.pool.ntp.org
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#307746: smbclient: Port option (-p) is ignored
Package: smbclient Version: 3.0.14a-1 Severity: normal I have a samba server listening on port 1390. To use smbclient to connect to it, I have to use the -p 1390 option. Since upgrading to 3.0.14a-1, smbclient has started ignoring -p (or --port, for that matter): # smbclient -U user -W DOMAIN -p 1390 //server/share timeout connecting to 160.19.25.253:445 timeout connecting to 160.19.25.253:139 Error connecting to 160.19.25.253 (Operation already in progress) Connection to 160.19.25.253 failed Thanks and Regards, Frank -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11-3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages smbclient depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcomerr2 1.37-2 common error description library ii libkrb531.3.6-2 MIT Kerberos runtime libraries ii libldap22.1.30-3 OpenLDAP libraries ii libncurses5 5.4-4Shared libraries for terminal hand ii libpopt01.7-5lib for parsing cmdline parameters ii libreadline44.3-11 GNU readline and history libraries ii samba-common3.0.14a-1Samba common files used by both th -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294891: kernel-source-2.6.10: fails to build
This is a bug in kernel-package 8.120: http://bugs.debian.org/294751 An upgrade to 8.121 will fix the issue. Regards, Frank On Sat, 12 Feb 2005 06:23:10 +, Grahame [EMAIL PROTECTED] wrote: Package: kernel-source-2.6.10 Version: 2.6.10-5 Severity: important Justification: fails to build from source I was trying to build a kernel using kernel-package. All was ok until I started the build. I did make-kpkg clean and that finished with no errors. I then did make-kpkg --revision=custom.1 kernel_image and got the following error: make: *** No rule to make target onf.vars', needed by tamp-configure'. Stop. I've compiled a number of kernels in the past using this method with no problems. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-source-2.6.10 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-4high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
