Bug 809602 - Mount command segfaults
Summary: Mount command segfaults
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.3
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Jeff Law
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Keywords: Regression
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-03 18:29 UTC by Donald Desjardin
Modified: 2016-11-24 16:08 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2012-06-20 12:10:14 UTC


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0763 normal SHIPPED_LIVE glibc bug fix and enhancement update 2012-06-19 20:35:39 UTC
Red Hat Bugzilla 709267 None None None Never

Internal Trackers: 709267

Description Donald Desjardin 2012-04-03 18:29:00 UTC
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 18:45:01 UTC
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 10:50:10 UTC
Created attachment 575081 [details]
valgrind --trace-children=no --leak-check=full --show-reachable=yes ...

Comment 4 Donald Desjardin 2012-04-04 10:54:38 UTC
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 16:25:16 UTC
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 18:19:41 UTC
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 18:21:19 UTC
Created attachment 575192 [details]
valgrind using mount.dd (a no-setuid copy of mount.nfs)

Comment 8 Jeff Law 2012-04-04 19:02:41 UTC
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 21:11:23 UTC
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 14:07:36 UTC
Stratus re-tested with RHEL 6.3 Beta-1 and this problem did not re-occur.

Comment 14 errata-xmlrpc 2012-06-20 12:10:14 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.

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.