Seg fault in 1.12.5

[Steve McIntyre]

Guys,

I've just had a bug reported in Debian about 1.12.5:

===========================================================================

$ cvs update -jupstream_version_2_12_0-CVS20031225 
-jupstream_version_2_13_0-rc1-CVS20040221
AUTHORS already contains the differences between 1.1.1.1 and 1.1.1.2
ChangeLog already contains the differences between 1.1.1.3 and 1.1.1.5
INSTALL already contains the differences between 1.1.1.1 and 1.1.1.3
R INSTALL.jp
Makefile.am already contains the differences between 1.1.1.3 and
1.1.1.5
cvs update: use `cvs add' to create an entry for `Makefile.in'
Segmentation fault

See attached ltrace.  Tarball of the repository is available upon
request.

Severity grave because:
 1) This renders cvs unusable if you hit the bug
 2) strcmp something to NULL makes me suspicious that it is part of
    a security hole

This bug was reproduced in the 1.12.2-2 version of the package.
Package version 1.12.1-7 did not exibit the bug. (I love
snapshot.debian.net
:) ), and managed to apply the update.

===========================================================================

The end of the trace output looks like:

__ctype_b_loc(0x080e3300, 0x080dc0e0, 3, 0x080d7088, 13794) = 0x4bee4fb8
strlen("upstream_version_2_12_0-CVS20031"...)    = 35
strchr("upstream_version_2_13_0-rc1-CVS2"..., 'u') = 
"upstream_version_2_13_0-rc1-CVS2"...
strncmp("upstream_version_2_13_0-rc1-CVS2"..., 
"upstream_version_2_12_0-CVS20031"..., 35) = 1
strchr("\n\tupstream_version_2_13_0-rc1:1."..., 'u') = 
"upstream_version_2_13_0-rc1:1.1."...
strncmp("upstream_version_2_13_0-rc1:1.1."..., 
"upstream_version_2_12_0-CVS20031"..., 35) = 1
strchr("\n\tupstream_version_2_12_0-CVS200"..., 'u') = 
"upstream_version_2_12_0-CVS20031"...
strncmp("upstream_version_2_12_0-CVS20031"..., 
"upstream_version_2_12_0-CVS20031"..., 35) = 0
malloc(8)                                        = 0x080dc118
strncpy(0x080dc118, "1.1.1.3", 7)                = 0x080dc118
strrchr("1.1.1.3", '.')                          = ".3"
strlen("1.1.1.3")                                = 7
malloc(8)                                        = 0x080dc128
sprintf(".0.", ".%d.", 0)                        = 3
strlen(".0.")                                    = 3
strncmp(".0.", ".1.3", 3)                        = -1
free(0x080dc128)                                 = <void>
strlen("1.1.1.3")                                = 7
strcmp("1.1.1.3", "1.1.1.3")                     = 0
strcmp("1.1.1.5", "1.1.1.5")                     = 0
strcmp("1.1.1.3", "1.1.1.5")                     = -2
strcmp("Sun Dec 28 02:49:35 2003", NULL <unfinished ...>

The reporter has given me his repository and I can reproduce the bug,
to the point of getting a core dump myself. Back trace shows the
crash comes from strmcp() in join_file(); ts_rcs is NULL:

(gdb) bt
#0  0x400f77d4 in strcmp () from /lib/libc.so.6
#1  0x0809a52e in join_file (finfo=0xbffff390, vers=0x80dba38) at
update.c:2299
#2  0x08097b92 in update_fileproc (callerdat=0x0, finfo=0xbffff390) at
update.c:764
#3  0x08086ea0 in do_file_proc (p=0x0, closure=0xbffff380) at
recurse.c:931
#4  0x08065ccd in walklist (list=0x80da798, proc=0x8086e20
<do_file_proc>, closure=0xbffff380) at hash.c:362
#5  0x08086a46 in do_recursion (frame=0xbffff420) at recurse.c:828
#6  0x08087244 in do_dir_proc (p=0x0, closure=0xbffff4d8) at
recurse.c:1211
#7  0x08065ccd in walklist (list=0x80d8380, proc=0x8086f50
<do_dir_proc>, closure=0xbffff4d8) at hash.c:362
#8  0x08086b56 in do_recursion (frame=0xbffff5a0) at recurse.c:858
#9  0x08086399 in start_recursion (fileproc=0x8097a30
<update_fileproc>, 
    filesdoneproc=0x8097fc0 <update_filesdone_proc>,
    direntproc=0x8098120 <update_dirent_proc>, 
    dirleaveproc=0x80984e0 <update_dirleave_proc>, callerdat=0x0,
    argc=0, argv=0x80d7768, local=0, which=7, 
    aflag=0, locktype=1, update_preload=0x0, dosrcs=1,
    repository_in=0xbffff5a0 "0z\t\b\177\t\b \201\t\b#10 0x080979e7 in
    do_update (argc=0, argv=0x0, xoptions=0x0, xtag=0x0, xdate=0x0,
    xforce=0, local=0, xbuild=0, 
    xaflag=0, xprune=0, xpipeout=0, which=0, xjoin_rev1=0x0,
    xjoin_rev2=0x0, preload_update_dir=0x0, xdotemplate=0, 
    repository=0x0) at update.c:502
#11 0x08097693 in update (argc=0, argv=0x80d7348) at update.c:416
#12 0x08073466 in main (argc=4, argv=0x80d7338) at main.c:1057
(gdb) up
#1  0x0809a52e in join_file (finfo=0xbffff390, vers=0x80dba38) at update.c:2299
2299            && strcmp (vers->ts_user, vers->ts_rcs) == 0
(gdb) p *vers
$1 = {vn_user = 0x0, vn_rcs = 0x80dc620 "1.5", vn_tag = 0x80dc610 "1.5", 
  ts_user = 0x80dc260 "Sun Dec 28 02:49:35 2003", ts_rcs = 0x0,
  options = 0x80dc5e8 "-ko", ts_conflict = 0x0, 
  tag = 0x0, date = 0x0, nonbranch = 0, entdata = 0x0, srcfile =
  0x80dc2f0}

I've never looked through this area of the code myself, so some help
here would be appreciated. The repository in question is quite small
(<10MB as a tar.bz2) if anybody wants a copy...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim."          [ seen in ucam.chat ]

signature.asc
Description: Digital signature