Bug 446801 - openssh gets "munmap_chunk(): invalid pointer:..." after glibc update
Summary: openssh gets "munmap_chunk(): invalid pointer:..." after glibc update
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-16 06:45 UTC by Michal Jaegermann
Modified: 2008-05-18 17:41 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-05-18 17:41:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
a terminal output from an attempted ssh connection (4.00 KB, text/plain)
2008-05-16 06:45 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2008-05-16 06:45:51 UTC
Description of problem:

After a rawhide update to glibc-2.8.90-1.x86_64 any attempt
of ssh to a box subjected to this treatment immediately ends
up with "closed by remote host" (after "Authentication succeeded"
in a debugging output).

If trying the same as root then one gets:
*** glibc detected *** sshd: root@pts/0: munmap_chunk(): invalid pointer:
0x00007fffb345911d ***
followed by a long trace which is attached.

Attempts to ssh out of a stricken box result in the following
(gdb output with openssh-debuginfo loaded):

Program terminated with signal 6, Aborted.
[New process 3101]
#0  0x0000000001a3b245 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install e2fsprogs.x86_64 gcc.x86_64
glibc.x86_64 keyutils.x86_64 krb5.x86_64 libselinux.x86_64 nspr.x86_64
nss.x86_64 openssl.x86_64 zlib.x86_64
(gdb) where
#0  0x0000000001a3b245 in raise () from /lib64/libc.so.6
#1  0x0000000001a3cdb3 in abort () from /lib64/libc.so.6
#2  0x0000000001a7b888 in __libc_message () from /lib64/libc.so.6
#3  0x0000000001a81188 in malloc_printerr () from /lib64/libc.so.6
#4  0x0000000001ad5ca0 in freeaddrinfo () from /lib64/libc.so.6
#5  0x00007f5712d5654a in ssh_connect (host=0x7f5714142bf7 "smok",
    hostaddr=0x7f5712f98e20, port=<value optimized out>,
    family=<value optimized out>, connection_attempts=1,
    timeout_ms=0x7fff1ad8fbb8, want_keepalive=1, needpriv=0, proxy_command=0x0)
    at sshconnect.c:410
#6  0x00007f5712d4bfda in main (ac=<value optimized out>, av=0x7fff1ad90320)
    at ssh.c:696
(gdb) f 5
#5  0x00007f5712d5654a in ssh_connect (host=0x7f5714142bf7 "smok",
    hostaddr=0x7f5712f98e20, port=<value optimized out>,
    family=<value optimized out>, connection_attempts=1,
    timeout_ms=0x7fff1ad8fbb8, want_keepalive=1, needpriv=0, proxy_command=0x0)
    at sshconnect.c:410
410             freeaddrinfo(aitop);
(gdb) l
405                     }
406                     if (sock != -1)
407                             break;  /* Successful connection. */
408             }
409
410             freeaddrinfo(aitop);
411
412             /* Return failure if we didn't get a successful connection. */
413             if (sock == -1) {
414                     error("ssh: connect to host %s port %s: %s",


Version-Release number of selected component (if applicable):
openssh-5.0p1-1.fc9.x86_64
glibc-2.8.90-1.x86_64

How reproducible:
every time

Comment 1 Michal Jaegermann 2008-05-16 06:45:51 UTC
Created attachment 305641 [details]
a terminal output from an attempted ssh connection

Comment 2 Tomas Mraz 2008-05-16 06:58:18 UTC
> any attempt of ssh to a box subjected to this treatment 
Didn't you mean any attempt of ssh FROM a box subjected to this treatment? The
trace is from ssh client.


Comment 3 Tomas Mraz 2008-05-16 07:15:34 UTC
I missed the 'Attempts to ssh out of a stricken box result in the following' :)
Ok seems both are broken. But I'd suspect something wrong within glibc anyway as
the resolver is what thoroughly changed in this glibc update.

Comment 4 Michal Jaegermann 2008-05-16 13:55:02 UTC
> But I'd suspect something wrong within glibc anyway ...
Yes, me too; unless stricter glibc checks uncovered something fishy in ssh.

Comment 5 Michal Jaegermann 2008-05-17 16:41:02 UTC
After an update to glibc-2.8.90-2 ssh started to work again.
So was this entirely a glibc fault or some "invalid pointer" complaints
were legitimate?

Comment 6 Tomas Mraz 2008-05-18 17:41:20 UTC
I didn't look at the sshd case but the ssh code was looking OK.



Note You need to log in before you can comment on or make changes to this bug.