Re: [PATCH] fix buffer overflow in util_run_program()

[Andrey Borzenkov <arvidjaar@mail.ru>]

[-- Attachment #1: Type: Text/Plain, Size: 1532 bytes --]

On Saturday 05 of September 2009 22:41:27 Alan Jenkins wrote:
> On 9/5/09, Florian Zumbiehl <florz@florz.de> wrote:
> > Hi,
> >
> >> > Now, what am I missing? I obviously do not understand much of
> >> > how udev works, but if the code of this function is not somewhat
> >> > pointless, then how would there not be a potential buffer
> >> > overflow?
> >> >
> >> > Florian
> >>
> >> Running "ls  -l" (two spaces) should be equivalent to "ls -l" (one
> >> space).  arg filled with spaces should be more or less equivalent
> >> to arg = "".  If it's not - then that's the real bug.
> >
> > well, I don't want to get into fixing semantic bugs, as there
> > generally doesn't seem to be much of a hint as to what the intended
> > semantics are - except that you wonder how the code's semantics
> > could actually be intentional. So I would suggest fixing the buffer
> > overflow for now, until someone feels like taking care of the
> > semantic bug.
> 
> My point was that I don't see any such semantic bug; I can't see
>  where the overflow would come from.
> 
> As far as I can see, the code uses strsep() which will correctly
> interpret a string of spaces as containing no tokens - and return
> NULL.
> 
> If I'm right, there's a different semantic bug - the use of strsep()
> to find a closing quote, which will fail for strings like
> 
> ' a '' b '
> 

If this is assumed to be two arguments ' a ' and ' b ', this function 
works correctly. What is really not possible, is to quote the quote.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]