[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#880659: [stunnel4] still random segfaults - gdb backtrace



control: reassign -1 stunnel4
control: retitle -1 stunnel4 calls pthread_rwlock_unlock on an rwlock which is not locked

Hi,

On 2019-04-21 16:26, Florian Lohoff wrote:
> 
> Hi,
> after installing corekeeper i got a coredump of the crashing stunnel.
> Installing some dbgsym packages i got this backtrace.
> 
> It seems the bug could be reassigned to glibc as it creashes
> in thread unlocking.
> 
> Its pretty interesting. It crashes in the "xend" instruction with
> is an opcode of the transactional memory feature. From the CPU type

Correct.

> it should be supported but concerning the Intel errata it might
> be disabled by microcode. Its not advertised as available in
> the cpuinfo - Should be flag "hle"
> 
> root@pax:/var/crash/0# lscpu
> Architecture:          x86_64
> CPU op-mode(s):        32-bit, 64-bit
> Byte Order:            Little Endian
> CPU(s):                8
> On-line CPU(s) list:   0-7
> Thread(s) per core:    2
> Core(s) per socket:    4
> Socket(s):             1
> NUMA node(s):          1
> Vendor ID:             GenuineIntel
> CPU family:            6
> Model:                 60
> Model name:            Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz
> Stepping:              3
> CPU MHz:               3699.951
> CPU max MHz:           3900.0000
> CPU min MHz:           800.0000
> BogoMIPS:              6983.94
> Virtualization:        VT-x
> L1d cache:             32K
> L1i cache:             32K
> L2 cache:              256K
> L3 cache:              8192K
> NUMA node0 CPU(s):     0-7
> Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb invpcid_single ssbd ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts flush_l1d

This is correct your CPU doesn't support hardware lock elision, and
anyway hardware lock elision is disabled by default since glibc 2.24-9.

> [ snip ]

> root@pax:/var/crash/0# gdb -c 15*core /usr/bin/stunnel4
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/bin/stunnel4...Reading symbols from /usr/lib/debug/.build-id/bb/b0710645254c912da337f32e7a2d40cd849ec3.debug...done.
> done.
> [New LWP 15247]
> [New LWP 15244]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/stunnel4 /etc/stunnel/stunnel-suucp.conf'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0x00007f51f7858c43 in _xend () at pthread_rwlock_unlock.c:38
> 38	pthread_rwlock_unlock.c: No such file or directory.
> [Current thread is 1 (Thread 0x7f51f64ad700 (LWP 15247))]
> (gdb) info thread
>   Id   Target Id         Frame 
> * 1    Thread 0x7f51f64ad700 (LWP 15247) 0x00007f51f7858c43 in _xend () at pthread_rwlock_unlock.c:38
>   2    Thread 0x7f51f8b13880 (LWP 15244) 0x00007f51f785856f in __GI___pthread_rwlock_wrlock (rwlock=0x5607e3c25070) at pthread_rwlock_wrlock.c:107
> (gdb) bt
> #0  0x00007f51f7858c43 in _xend () at pthread_rwlock_unlock.c:38
> #1  __GI___pthread_rwlock_unlock (rwlock=0x5607e3c68ce0) at pthread_rwlock_unlock.c:38
> #2  0x00007f51f8453f09 in CRYPTO_THREAD_unlock (lock=<optimized out>) at ../crypto/threads_pthread.c:79
> #3  0x00007f51f8422c9d in rand_bytes (buf=0x7f51f0006ec0 "\031e\342\244\035O2\226\235p", num=0, pseudo=0) at ../crypto/rand/md_rand.c:498
> #4  0x00007f51f835b551 in bnrand (pseudorand=0, rnd=0x7f51f0002a10, bits=2047, top=<optimized out>, bottom=<optimized out>) at ../crypto/bn/bn_rand.c:46

The crash happens there because pthread_rwlock_unlock is called on an
rwlock which is not locked. This is an undefined behaviour, so calling
xend is perfectly fine here even if the CPU doesn't support it.

The problem is at the application level, I am therefore reassigning the
bug back to stunnel4.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature


Reply to: