[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: bug in arts
From:       Dan Stone <dan () headzofstate ! com>
Date:       2002-07-22 7:39:01
[Download RAW message or body]

> > From reading the spec provided with the source, it seems that 'length' is
> > the maximum amount of samples you want back from the read...I can't
> > figure out why you'd want to limit this, but maybe someone with more
> > knowledge of the aRts server could comment on that...once that's nailed
> > down, seems like a quick fix.  I just set 'length' to an insanely large
> > number, and it compiled fine =P
>
> ... and you created a fine buffer overflow by doing so. The ov_read_float
> will now probably write an insane amount of samples into your sample buffer
> (pcm_channels), no matter how long it actually was.
>
> regards,
> 	matze

Oh, I realize it wasn't the *proper* solution, nor have I tested actually 
running the built aRts package -- the fact that it had compiled properly was 
just an offhand comment.  Well, what would you suggest for a value, then?  In 
the way it's implemented in gsldatahandle-vorbis.c, this is the relevant 
code...
~~~~~~~~~~~~~~
static void
read_packet (VorbisHandle *vhandle)
gfloat **pcm = NULL;
gint stream_id, i;

vhandle->pcm_pos = ov_pcm_tell ( &vhandle->ofile) - vhandle->soffset;
vhandle->pcm_length = ov_read_float (&vhandle->ofile, &pcm, &stream_id);
~~~~~~~~~~~~~~~

So, you can't know the size of the buffer (pcm here) at the time of the 
function call, unless there's something I'm missing...

~D.A. Stone

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]