Bug 809602 - Mount command segfaults
Summary: Mount command segfaults
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Jeff Law
QA Contact: qe-baseos-tools-bugs
Depends On:
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)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-06-20 12:10:14 UTC
Target Upstream Version:

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

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 709267 0 unspecified CLOSED ssh client segfaults when nscd is running 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2012:0763 0 normal SHIPPED_LIVE glibc bug fix and enhancement update 2012-06-19 20:35:39 UTC

Internal Links: 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
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.


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: =========

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.


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.


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