Bug 809602
| Summary: | Mount command segfaults | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Donald Desjardin <donald.desjardin> | ||||||||
| Component: | glibc | Assignee: | Jeff Law <law> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-tools-bugs | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.3 | CC: | fweimer, jparadis, kevin.paetzold, mfranc, robert.evans, wgomerin | ||||||||
| Target Milestone: | rc | Keywords: | Regression | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-06-20 12:10:14 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
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 Created attachment 575081 [details]
valgrind --trace-children=no --leak-check=full --show-reachable=yes ...
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. 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... 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.
Created attachment 575192 [details]
valgrind using mount.dd (a no-setuid copy of mount.nfs)
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! 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 ;-) Stratus re-tested with RHEL 6.3 Beta-1 and this problem did not re-occur. 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 |
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