Bug 472128 - automount segfaults in prune_host_list
automount segfaults in prune_host_list
Status: CLOSED DUPLICATE of bug 455550
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jeff Moyer
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-11-18 16:09 EST by Chris Schanzle
Modified: 2008-11-18 16:17 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-18 16:16:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fix a null pointer dereference (775 bytes, patch)
2008-11-18 16:17 EST, Jeff Moyer
no flags Details | Diff

  None (edit)
Description Chris Schanzle 2008-11-18 16:09:53 EST
[CentOS 5.2]
Description of problem:

We recently decommissioned an NFS server.  Users still have references to old methods of getting to users home directories, such as /home/fs3a/user (we now use /home/user, but we retained backward compatibility for convenience).  E.g., in NIS map auto.home, we have entries like:

fs3a home.server.gov:/a/home/&

The old server was turned off last week.  But sometimes users have symlink that point to /home/fs3a/user/foo, or use the style in shell scripts,or it's embedded in binaries.

The problems started shortly after the server was turned off.  Today (three days later), 8 systems had no automount daemons running (existing mounts continued to work, so not many people complained).

Note that home.server.gov is a CNAME record to a 3-interface multihomed server.  The records are still in DNS; the server is turned off.

Core was generated by `automount'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002aaaab94fdc2 in prune_host_list () from /usr/lib64/autofs/mount_nfs.so
(gdb) bt
#0  0x00002aaaab94fdc2 in prune_host_list () from /usr/lib64/autofs/mount_nfs.so
#1  0x00002aaaab94e492 in mount_mount () from /usr/lib64/autofs/mount_nfs.so
#2  0x00002aaaab72503f in parse_init () from /usr/lib64/autofs/parse_sun.so
#3  0x00002aaaab72604f in parse_mount () from /usr/lib64/autofs/parse_sun.so
#4  0x00002aaaabf881b0 in lookup_mount () from /usr/lib64/autofs/lookup_yp.so
#5  0x00002b974b110aaf in lookup_nss_mount () from /usr/sbin/automount
#6  0x00002b974b109c05 in expire_proc_indirect () from /usr/sbin/automount
#7  0x00002b974b563307 in start_thread () from /lib64/libpthread.so.0
#8  0x00002b974bc5bded in clone () from /lib64/libc.so.6

The "killer" user was one who had put /home/fs3a/user/... in their PATH in their login script.  Automount would die very, very frequently and consistently when they tried to start a shell (or log in the console).

I have numerous core files I can make available or do additional probing on request.

Version-Release number of selected component (if applicable):

How reproducible:
Consistently, given the right circumstances.

Other notes:
I compiled Fedora 9's autofs .src.rpm under mock/centos had no significant improvement on one test box: autofs-5.0.3-15.i386
Comment 1 Jeff Moyer 2008-11-18 16:16:52 EST
This is a duplicate of 455550, so I'm going to close it (even though that bugzilla is private).  This will be addressed in RHEL 5.3.  I'll attach the patch here for verification.

*** This bug has been marked as a duplicate of bug 455550 ***
Comment 2 Jeff Moyer 2008-11-18 16:17:47 EST
Created attachment 323964 [details]
fix a null pointer dereference

Please feel free to reopen this bug if the attached patch (or the 5.3 package) does not actually address the issue.


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