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

Bug#872727: marked as done (Bug#872727: libc6-dev: gethostbyname segfaults with libnss_resolve.so.2 for static binaries)

Your message dated Tue, 6 Sep 2022 21:13:03 +0200
with message-id <YxebvzA9e+CbycA4@aurel32.net>
and subject line Re: Bug#865469: libc6-dev: a program crashes if it is statically linked against OpenSSL
has caused the Debian Bug report #865469,
regarding Bug#872727: libc6-dev: gethostbyname segfaults with libnss_resolve.so.2 for static binaries
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 owner@bugs.debian.org
immediately.)


-- 
865469: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865469
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6-dev
Version: 2.24-11+deb9u1
Severity: normal

Dear Maintainer,

with glibc 2.24 (reproducible on 64-bit Debian 9 or Ubuntu 17.04),
gethostbyname() always segfaults if the binary was linked statically:

$ echo -e "#include <netdb.h>\nint main(void){gethostbyname(\"foo\");}" >foo.c && \
gcc -g -static foo.c && ./a.out
/tmp/ccp8JNGC.o: In function `main':
/tmp/foo.c:2: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
Segmentation fault
$ gdb a.out                                                 
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
[...]
Reading symbols from a.out...done.
(gdb) run
Starting program: /tmp/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff72ac040 in __pthread_initialize_minimal_internal () at nptl-init.c:460
#2  0x00007ffff72ab5e1 in _init () at ../sysdeps/x86_64/crti.S:72
#3  0x00007ffff76cc830 in ?? () from /lib/x86_64-linux-gnu/libnss_myhostname.so.2
#4  0x0000000000478a7a in call_init.part ()
#5  0x0000000000478c35 in _dl_init ()
#6  0x000000000047089e in dl_open_worker ()
#7  0x000000000046e0f4 in _dl_catch_error ()
#8  0x000000000047024c in _dl_open ()
#9  0x0000000000439ba2 in do_dlopen ()
#10 0x000000000046e0f4 in _dl_catch_error ()
#11 0x0000000000439bd7 in dlerror_run ()
#12 0x0000000000439da3 in __libc_dlopen_mode ()
#13 0x0000000000436b3b in __nss_lookup_function ()
#14 0x0000000000436d45 in __nss_next2 ()
#15 0x000000000043504a in gethostbyname_r ()
#16 0x0000000000434d93 in gethostbyname ()
#17 0x0000000000400b2e in main () at foo.c:2

In my upstream bug report, a commenter noted that this weren't reproducible in
Fedora's glibc 2.24 or 2.25, suggesting this "could be a Debian or Ubuntu
patch": https://sourceware.org/bugzilla/show_bug.cgi?id=21975

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/64 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-dev depends on:
ii  libc-dev-bin    2.24-11+deb9u1
ii  libc6           2.24-11+deb9u1
ii  linux-libc-dev  4.9.30-2+deb9u3

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc     <none>
ii  manpages-dev  4.10-2

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 2.34-1

On 2017-08-20 19:12, Aurelien Jarno wrote:
> control: forcemerge 872727 -1
> 
> On 2017-06-21 20:48, Mikulas Patocka wrote:
> > Package: libc6-dev
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate ***
> > 
> >    * What led up to the situation?
> > 
> > Programs can't be statically linked against OpenSSL in Debian Stretch.
> > 
> >    * What exactly did you do (or not do) that was effective (or
> >      ineffective)?
> > 
> > Try to compile this program with this command:
> > gcc -static hello.c -lssl -lcrypto -ldl -pthread
> > 
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <openssl/ssl.h>
> > 
> > int main(void)
> > {
> >         OpenSSL_add_ssl_algorithms();
> >         printf("Hello World!\n");
> >         return 0;
> > }
> > 
> >    * What was the outcome of this action?
> > 
> > If you run the statically linked program, you get a crash in glibc startup
> > code:
> > #0  0x0000000000000000 in ?? ()
> > #1  0x00000000006296c6 in __register_frame_info.part.4 ()
> > #2  0x00000000004017fd in frame_dummy ()
> > #3  0x000000000058c2d7 in __libc_csu_init ()
> > #4  0x000000000058b95b in generic_start_main ()
> > #5  0x000000000058bc3e in __libc_start_main ()
> > #6  0x000000000040172a in _start ()
> > 
> >    * What outcome did you expect instead?
> > 
> > The compiled program should work.
> 
> This is an upstream issue, due to two changes:
> 1) libssl is now linked with pthread
> 2) libssl now try to run getaddrinfo or gethostbyname
> 
> This trigger the following bug:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21975
> 
> As a workaround you might want to link your binary against libssl1.0
> instead and without -pthread.

Since glibc 2.34, libpthread has been integrated into libc. As a side
effect this fixes this bug. I am therefore closing this bug.

Regards
Aurelien

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

--- End Message ---
Reply to: