Bug 472128

Summary: automount segfaults in prune_host_list
Product: Red Hat Enterprise Linux 5 Reporter: Chris Schanzle <bugzilla>
Component: autofsAssignee: Jeff Moyer <jmoyer>
Status: CLOSED DUPLICATE QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: ikent
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-18 21:16:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
fix a null pointer dereference none

Description Chris Schanzle 2008-11-18 21:09:53 UTC
[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):
autofs-5.0.1-0.rc2.88.i386
autofs-5.0.1-0.rc2.88.x86_64

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 21:16:52 UTC
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 21:17:47 UTC
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.

Thanks!