[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: AIX 5.1 client crash (buffer-overflow)

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-01-15 03:40:31 CET

Travis <svn@castle.fastmail.fm> writes:

[This is a subject for dev@s.t.o]

> I'm getting a crash from the following:
>
> subversion/libsvn_subr/subst.c:
> 561: readlen = sizeof (buf);
> 562: while (readlen == sizeof (buf))
> 563: {
> 564: SVN_ERR (svn_stream_read (s, buf, &readlen));
> 565: buf[readlen] = '\0';
>
> buf is 102401 bytes in size.
> readlen gets set to 102401.
> svn_stream_read does not modify readlen.
> buf[102401] is out-of-range and causes the crash.
>
> Clearly, something is wrong.

Most definitely! The line assigning to buf[102401] is overwriting one
byte of the stack. I suspect we have been getting away with this
because our usual platforms have padding bytes (at least 3) between
the end of buf and anything important, and they allow assignment to
those bytes.

Try the patch below. Probably a 1.0 candidate.

Index: subversion/libsvn_subr/subst.c
===================================================================
--- subversion/libsvn_subr/subst.c (revision 8293)
+++ subversion/libsvn_subr/subst.c (working copy)
@@ -558,8 +558,8 @@
   assert (eol_str || keywords);
   interesting = (eol_str && keywords) ? "$\r\n" : eol_str ? "\r\n" : "$";
 
- readlen = sizeof (buf);
- while (readlen == sizeof (buf))
+ readlen = sizeof (buf) - 1;
+ while (readlen == sizeof (buf) - 1)
     {
       SVN_ERR (svn_stream_read (s, buf, &readlen));
       buf[readlen] = '\0';

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 15 03:42:33 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.