Bug 1071171

Summary: crash when linking libtspi and libmysqlclient
Product: Red Hat Enterprise Linux 7 Reporter: Nikos Mavrogiannopoulos <nmavrogi>
Component: trousersAssignee: Avesh Agarwal <avagarwa>
Status: CLOSED ERRATA QA Contact: Jaroslav Aster <jaster>
Severity: high Docs Contact:
Priority: urgent    
Version: 7.0CC: avagarwa, dane, enrico.tagliavini, fkrska, fred.passos, gerd, jaster, jherrman, jkurik, joey, jrieden, ksrot, mkolbas, pvrabec, redhat, rh-bugs, shamotek, tbskyd, volker27
Target Milestone: rcKeywords: EasyFix, Patch, Reproducer, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: trousers-0.3.13-1.el7 Doc Type: Bug Fix
Doc Text:
Previously, a program that linked against both the libmysqlclient library and the libtspi library terminated unexpectedly with a segmentation fault. This update distinguishes the name of the related constructor from the destructor, which allows the loader to call the correct function, and thus prevents the described crash.
Story Points: ---
Clone Of:
: 1224558 (view as bug list) Environment:
Last Closed: 2015-11-19 13:53:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1224558    

Description Nikos Mavrogiannopoulos 2014-02-28 08:09:11 UTC
[This is a copy of #1069079]

A trivial program that links against both libmysqlclient and libtspi will crash with a segfault.

Version-Release number of selected component (if applicable):
trousers-devel-0.3.11.2-3.el7
mariadb-devel-5.5.35-2.el7

How reproducible:
$ cat test.c
int main ()
{
  return 0;
}

$ gcc test.c -o test  -L/usr/lib64/mysql -lmysqlclient -ltspi 

$ ./test
Segmentation fault (core dumped)

backgrace in valgrind:

==3836== Invalid read of size 4
==3836==    at 0x3942009FE0: pthread_mutex_lock (pthread_mutex_lock.c:66)
==3836==    by 0x31CFE22BC3: host_table_final (hosttable.c:54)
==3836==    by 0x394140F8E9: _dl_fini (dl-fini.c:252)
==3836==    by 0x39418394C8: __run_exit_handlers (exit.c:82)
==3836==    by 0x3941839514: exit (exit.c:104)
==3836==    by 0x3941821D6B: (below main) (libc-start.c:319)
==3836==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==3836== 
==3836== 
==3836== Process terminating with default action of signal 11 (SIGSEGV)
==3836==  Access not within mapped region at address 0x18
==3836==    at 0x3942009FE0: pthread_mutex_lock (pthread_mutex_lock.c:66)
==3836==    by 0x31CFE22BC3: host_table_final (hosttable.c:54)
==3836==    by 0x394140F8E9: _dl_fini (dl-fini.c:252)
==3836==    by 0x39418394C8: __run_exit_handlers (exit.c:82)
==3836==    by 0x3941839514: exit (exit.c:104)
==3836==    by 0x3941821D6B: (below main) (libc-start.c:319)


Actual results:
The program segfaults.

Expected results:
The program should exit normally.

Comment 2 Nikos Mavrogiannopoulos 2014-02-28 08:16:11 UTC
Adding printf() on the constructor and destructor reveals that when linking with both mysqlclient and tspi, only the destructor of tspi is called but not the constructor (and thus the crash).

Comment 3 RHEL Program Management 2014-03-22 05:54:34 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 4 Steve Grubb 2014-06-12 19:32:50 UTC
This package should be rebased to the current release to fix this and several other problems.

Comment 7 Gerd v. Egidy 2015-04-02 12:43:19 UTC
any news about this one?

It still occurs on 7.1.

Comment 11 Enrico Tagliavini 2015-04-09 12:08:52 UTC
Since the release of Red Hat Enterprise Linux 7.1 this issue is more serious. Now gnutls links against libtspi and any application using gnutls is potentially affected. One real world scenario when this issue happens is zabbix server. I tried with packages from EPEL repo, versions below the trace (note this test system is running CentOS 7.1, not RHEL):

[root@cfzabbix zabbix]# su zabbixsrv -s /bin/bash -c 'valgrind /usr/sbin/zabbix_server_mysql'
==28745== Memcheck, a memory error detector
==28745== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==28745== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==28745== Command: /usr/sbin/zabbix_server_mysql
==28745==
==28745== Invalid read of size 4
==28745==    at 0x7D56C00: pthread_mutex_lock (pthread_mutex_lock.c:50)
==28745==    by 0xB6B1BB3: host_table_final (hosttable.c:54)
==28745==    by 0x400FB59: _dl_fini (dl-fini.c:253)
==28745==    by 0x79C4E48: __run_exit_handlers (exit.c:77)
==28745==    by 0x79C4E94: exit (exit.c:99)
==28745==    by 0x46C0B3: daemon_start (in /usr/sbin/zabbix_server_mysql)
==28745==    by 0x79ADAF4: (below main) (libc-start.c:274)
==28745==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==28745==    
==28745==    
==28745== Process terminating with default action of signal 11 (SIGSEGV)
==28745==  Access not within mapped region at address 0x18
==28745==    at 0x7D56C00: pthread_mutex_lock (pthread_mutex_lock.c:50)
==28745==    by 0xB6B1BB3: host_table_final (hosttable.c:54)
==28745==    by 0x400FB59: _dl_fini (dl-fini.c:253)
==28745==    by 0x79C4E48: __run_exit_handlers (exit.c:77)
==28745==    by 0x79C4E94: exit (exit.c:99)
==28745==    by 0x46C0B3: daemon_start (in /usr/sbin/zabbix_server_mysql)
==28745==    by 0x79ADAF4: (below main) (libc-start.c:274)
==28745==  If you believe this happened as a result of a stack
==28745==  overflow in your program's main thread (unlikely but
==28745==  possible), you can try to increase the size of the
==28745==  main thread stack using the --main-stacksize= flag.
==28745==  The main thread stack size used in this run was 8388608.

[root@cfzabbix ~]# rpm -qa | grep 'zabbix\|gnutls\|trousers'
zabbix22-2.2.7-1.el7.x86_64
gnutls-3.3.8-12.el7.centos.x86_64
zabbix22-dbfiles-mysql-2.2.7-1.el7.noarch
zabbix22-web-mysql-2.2.7-1.el7.noarch
zabbix22-agent-2.2.7-1.el7.x86_64
trousers-0.3.11.2-3.el7.x86_64
zabbix22-web-2.2.7-1.el7.noarch
zabbix22-server-2.2.7-1.el7.noarch
trousers-debuginfo-0.3.11.2-3.el7.x86_64
zabbix22-server-mysql-2.2.7-1.el7.x86_64
gnutls-debuginfo-3.3.8-12.el7.centos.x86_64

I recompiled gnutls package from the original SRPM and edited the spec file to pass the --without-tpm option to %configure. This way gnutls doesn't link to libtspi anymore and zabbix server can start and operate without problems. This is just a workaround however and not a proper solution.

Then I noticed this bug is a copy of bug #1069079 against Fedora. I tried the proposed patch (now included in both Fedora and trousers upstream) applying it to the original SRPM and recompiled, Zabbix works like a charm.

Given gnutls is fairly common and with the latest update Red Hat enabled tpm support in it the chances of collisions are increased and affects also program not directly linking libtspi as in the case of Zabbix server

[root@cfzabbix etc]# objdump -p /usr/sbin/zabbix_server_mysql  | grep NEEDED
  NEEDED               libmysqlclient.so.18
  NEEDED               libiksemel.so.3
  NEEDED               libxml2.so.2
  NEEDED               libodbc.so.2
  NEEDED               libnetsnmp.so.31
  NEEDED               libssl.so.10
  NEEDED               libcrypto.so.10
  NEEDED               libm.so.6
  NEEDED               libssh2.so.1
  NEEDED               libOpenIPMI.so.0
  NEEDED               libOpenIPMIposix.so.0
  NEEDED               libldap-2.4.so.2
  NEEDED               liblber-2.4.so.2
  NEEDED               libcurl.so.4
  NEEDED               libdl.so.2
  NEEDED               libresolv.so.2
  NEEDED               libc.so.6

which links to /lib64/libiksemel.so.3 which links to gnutls which links to libtspi.

Comment 14 tbsky 2015-04-18 07:53:34 UTC
hi:
    will redhat release new trousers to fix the problem? to run zabbix now I just downgrade gnutls. but I hope this can be fixed.

Comment 20 Volker Fröhlich 2015-04-25 21:00:49 UTC
I'm the Zabbix maintainer and I'd love to know what your plans are.

Comment 21 Ender 2015-04-27 12:25:54 UTC
There is already a patch http://sourceforge.net/p/trousers/bugs/172/ - so what do you guys still need to fix the package?

Comment 26 Tomas Brandysky 2015-05-12 09:34:11 UTC
when will RedHat release a new package with the patch ?

Comment 31 errata-xmlrpc 2015-11-19 13:53:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2104.html