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

List:       busybox
Subject:    Re: [Patch] fix unsigned long fast_strtoul_10(char **endptr) for Linux 2.4
From:       walter harms <wharms () bfs ! de>
Date:       2012-02-28 16:46:09
Message-ID: 4F4D04D1.30808 () bfs ! de
[Download RAW message or body]



Am 28.02.2012 17:08, schrieb Denys Vlasenko:
> On Tue, Feb 28, 2012 at 5:04 PM, walter harms <wharms@bfs.de> wrote:
>> Hello Ralf,
>> the current version has a major problem when you consider this: "0\0"
>> the patch ( change != into > ) will only catch the current bug
>> (reading the last 0 wrong what actually happens on 2.4) but when the main
>> code reads again (perhaps to get additional information) it will read
>> beyond \0.
>> char *cp="0\n";
>>  fast_strtoul_10(&cp); <-- will work fine
>>  fast_strtoul_10(&cp); <-- will break
> 
> The whole point of fast_strtoul_10 is that it _knows_ that /proc data
> it is fed with is well-formatted. That's why it doesn't do a lot of error
> checking, for example: it simply assumes all chars > ' ' will be
> decimal digits.
> 
> The thing you are pointing out is just another case of lack of error check:
> fast_strtoul_10() is not supposed to be called when you are unsure that
> field you are trying to parse actually exists.
> 

i noticed that also, the difference for me is that ignoring \0 may cause an
segfault, while taking \n for a number will result in bad data.

re,
 wh
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]