Bug 809602 - Mount command segfaults
Mount command segfaults
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc (Show other bugs)
6.3
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Jeff Law
qe-baseos-tools
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-03 14:29 EDT by Donald Desjardin
Modified: 2016-11-24 11:08 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 08:10:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The output from the mount command (5.02 KB, text/plain)
2012-04-03 14:29 EDT, Donald Desjardin
no flags Details
valgrind --trace-children=no --leak-check=full --show-reachable=yes ... (139.56 KB, text/plain)
2012-04-04 06:50 EDT, Donald Desjardin
no flags Details
valgrind using mount.dd (a no-setuid copy of mount.nfs) (1.89 KB, text/plain)
2012-04-04 14:21 EDT, Donald Desjardin
no flags Details

  None (edit)
Description Donald Desjardin 2012-04-03 14:29:00 EDT
Created attachment 574927 [details]
The output from the mount command

Description of problem:
  When mounting any non RHEL6.2 mount, I get a segfault (see attachment).

Version-Release number of selected component (if applicable):
  This was an IPL of RHEL6.3-Alpha-1

How reproducible:
  Every time

Steps to Reproduce:
1. mount (or automount) any non RHEL6.2 export
2.
3.
  
Actual results:
  Did not mount

Expected results:
  I expected it to mount

Additional info:
  If I force nfsvers=3 in the /etc/nfsmount.conf file, it happens even on RHEL6.2 exported file system
Comment 2 Jeff Law 2012-04-03 14:45:01 EDT
This looks like heap corruption and is probably a problem with mount.nfs.
Could you install the nfs-utils debuginfo package, then run the command under the control of valgrind?

debuginfo-install nfs-utils
valgrind --trace-children=yes  /sbin/mount ftldataserv:/loc/data1 /mnt

That may give us additional information about when/how the heap gets corrupted.

Based on those results I'll either investigate myself (if the problem points to glibc itself) or pass along to the nfs-utils maintainer.

Thanks
Comment 3 Donald Desjardin 2012-04-04 06:50:10 EDT
Created attachment 575081 [details]
valgrind --trace-children=no --leak-check=full --show-reachable=yes ...
Comment 4 Donald Desjardin 2012-04-04 06:54:38 EDT
Sorry this took so long.  First, I had to resolve all the warnings from debuginfo-install, and then there was a setuid/setgid problem running valgrind.

Even then, I could not run valgrind with the "--trace-children=yes", so on the advise of the valgrind output I ran:

   valgrind --trace-children=no --leak-check=full --show-reachable=yes ...

The output has been added to this bug as an attachment.
Comment 5 Jeff Law 2012-04-04 12:25:16 EDT
No worries.  Unfortunately I really need the child trace.  When mounting an NFS filesystem, /sbin/mount execs /sbin/mount.nfs and it's mount.nfs that's failing.

I was just reading up on mount.nfs and it appears it can be trivially called without using the mount front-end.  So, the output from

valgrind /sbin/mount.nfs ...

Thanks and sorry for the difficulties...
Comment 6 Donald Desjardin 2012-04-04 14:19:41 EDT
Using mount.nfs gave the same setuid/setgid error, so I got fed up and copied mount.nfs to mount.dd with no setuid bit.

I ran:
    valgrind --trace-children=yes /sbin/mount.dd ftldataserv:/loc/data1 /mnt

...while capturing the output, and guess what, the file system actually mounted!

To umount the filesystem I had to do the same thing with /sbin/umount.nfs (copy to umount.dd w/out the setuid bit).

This didn't really solve anything, as running the mount.dd or umount.dd commands w/out using valgrind still fails with what looks like the original invalid pointer message:

  # /sbin/mount.dd ftldataserv:/loc/data1 /mnt
  *** glibc detected *** /sbin/mount.dd: munmap_chunk(): invalid pointer: 0x00007f39dd73e4c3 ***
  ======= Backtrace: =========
  /lib64/libc.so.6(+0x3975a752c6)[0x7f39dc8322c6]
  /lib64/libc.so.6(+0x3975b210d9)[0x7f39dc8de0d9]
  /lib64/libc.so.6(+0x3975b214ab)[0x7f39dc8de4ab]
  /lib64/libc.so.6(getservbyname_r+0x183)[0x7f39dc8c1563]
  /lib64/libc.so.6(+0x3975ace4c2)[0x7f39dc88b4c2]
  /lib64/libc.so.6(+0x3975acf208)[0x7f39dc88c208]
  /lib64/libc.so.6(getaddrinfo+0x150)[0x7f39dc88ea50]
  ...

I've attached the new valgrind output, but not sure if this will tell you anything since the command actually works in that case.
Comment 7 Donald Desjardin 2012-04-04 14:21:19 EDT
Created attachment 575192 [details]
valgrind using mount.dd (a no-setuid copy of mount.nfs)
Comment 8 Jeff Law 2012-04-04 15:02:41 EDT
Thanks.  That's helpful.  Something is passing what appears to be a bogus value to free (0x607b4c3).  The call chain may be pointing to a glibc problem; there's certainly enough information for me to chew on it for a while and see if I can form a theory as to what's happening.

Thanks!
Comment 9 Jeff Law 2012-04-04 17:11:23 EDT
QE --

This is more fallout from 797094.  There was a follow-up change that the sec team didn't reference in 797094.  We need a QE ack ;-)
Comment 12 Robert N. Evans 2012-04-24 10:07:36 EDT
Stratus re-tested with RHEL 6.3 Beta-1 and this problem did not re-occur.
Comment 14 errata-xmlrpc 2012-06-20 08:10:14 EDT
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.

http://rhn.redhat.com/errata/RHBA-2012-0763.html

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