Bug 13837 - ypinit (ypxfr) dumps core
Summary: ypinit (ypxfr) dumps core
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ypserv
Version: 6.2
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-12 22:33 UTC by Matthew Galgoci
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-03-26 21:21:56 UTC
Embargoed:


Attachments (Terms of Use)

Description Matthew Galgoci 2000-07-12 22:33:10 UTC
Ypxfr dumps core while performing a database init from 
a remote master if network conditions are poor. The yp 
databases are left in an unpredictably inconsistent
state. Here are some backtraces:

[root@hardrock /root]# gdb -c core
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `/usr/lib/yp/ypxfr -f -h lacrosse.corp.redhat.com -c
-d devel.redhat.com passwd.'.
Program terminated with signal 11, Segmentation fault.
#0  0x400f9af4 in ?? ()
(gdb) file /usr/lib/yp/ypxfr
Reading symbols from /usr/lib/yp/ypxfr...(no debugging symbols
found)...done.
(gdb) bt
#0  0x400f9af4 in ?? () from /lib/libc.so.6
#1  0x40104446 in ?? () from /lib/libc.so.6
#2  0x804b235 in xdr_ypresp_xfr ()
#3  0x8049d8d in strcpy ()
#4  0x804a7fe in strcpy ()
#5  0x4004c9cb in ?? () from /lib/libc.so.6
(gdb) 


[root@hardrock /root]# gdb -c core.1
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `/usr/lib/yp/ypxfr -f -h lacrosse.corp.redhat.com -c
-d devel.redhat.com ypserve'.
Program terminated with signal 11, Segmentation fault.
#0  0x400f9af4 in ?? ()
(gdb) file /usr/lib/yp/ypxfr
Reading symbols from /usr/lib/yp/ypxfr...(no debugging symbols
found)...done.
(gdb) bt
#0  0x400f9af4 in ?? () from /lib/libc.so.6
#1  0x40104446 in ?? () from /lib/libc.so.6
#2  0x804b235 in xdr_ypresp_xfr ()
#3  0x8049d8d in strcpy ()
#4  0x804a7fe in strcpy ()
#5  0x4004c9cb in ?? () from /lib/libc.so.6
(gdb) 

So you see, it seems to be very consistent where it core dumps.

Also, aren't strcpy() a possible buffer overrun and as such a 
possible security hole?

Comment 1 Matthew Galgoci 2000-07-12 23:21:34 UTC
How to reproduce core dump:

The failure above can be reproduced very easily. Simply
perform a ypinit -s lacrosse.corp.redhat.com and then 
after the first map has transfered, execute the following
script:

nb: 1) don't attempt to run this script remotely ;-)
    2) if at first you don't succed, keep trying
    3) this also affects the current beta

#!/bin/bash
n=3

while true
do
	/sbin/ipchains -P input DENY
	/sbin/ipchains -P output DENY
	echo DENY
	sleep $n

	/sbin/ipchains -P input ACCEPT
	/sbin/ipchains -P output ACCEPT
	echo ACCEPT
	sleep $n

	/sbin/ipchains -P input REJECT
	/sbin/ipchains -P output REJECT
	echo REJECT
	sleep $n
done

Comment 2 Florian La Roche 2000-08-07 14:00:03 UTC
Can you still reproduce this with newer binaries/kernels?


Comment 3 Alexander Larsson 2002-03-26 20:41:31 UTC
I can't reproduce this. Can you? I had to transfer from devserv instead of
lacrosse though, since i didn't get anything from lacrosse. Maybe i had the
wrong domain name.

I also got messages about ypxfrd not running, maybe that affects whether this
bug is triggered.


Comment 4 Matthew Galgoci 2002-03-26 21:21:51 UTC
I have not seen this bug exhibit itself since the 7.x yp errata went out.

Comment 5 Alexander Larsson 2002-03-26 21:29:00 UTC
Cool. Then i'm gonna close it.


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