Hi Robert,
I agree we should offer this upstream first. It's not a serious issue
but I decided to tackle it is a challenge or practice in case we get
another report against something more critical.
This round of testing by the team at CMU did not work properly with
binaries that abort if getuid()!=0, so they will likely do another batch
of these. They seem to be using a lot of compute power to do it.
The null deref is of centry, given as second parameter to set() in the
special circumstances found by Mayhem's analysis:
> (gdb) bt full
> #0 0x0000000000404a33 in set (t=0x7fffffffcce0 "<", ip=0x0) at spec.c:177
> type = 8
> kw = 0x7fffffffcce0 "<"
> val = 0x0
> gr = 0xffffffff
> pw = 0x7fffffffd4f0
> m = 0x800d8f620 <environ>
> value = 14210368
> ep = 0x23 <Address 0x23 out of bounds>
> #1 0x000000000040458a in mtree_readspec (fi=0x800d8d540 <_IO_2_1_stdin_>) at
> spec.c:99
On 27/06/13 23:35, Robert Millan wrote:
> Silly me, looks like I can't read C anymore.
It seems odd sometimes to see things written in optimised C, whereas a
higher-level language or regexp would have simply done this right, and
still been more than fast enough.
> I guess it can be simplified this way?
>
>> if (!*p)
>> continue;
>>
>> if (*p == '#')
>> {
>> ...
>> }
Yes it perhaps should, and it does look simpler, though actually the
same number of lines.
What can't be done though is have (!*p) trigger c_next=0. or else a line
continuation character doesn't work any more on an empty line.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ccca35.4080...@pyro.eu.org
