[Crash-utility] [PATCH]: double free in trace extension

[Dave Anderson]

----- Original Message -----
> On Wed, May 9, 2012 at 3:57 PM, Dave Anderson <anderson at redhat.com>
> wrote:
> >
> >
> > ----- Original Message -----
> >> >> First, just like some other contributors, I've come across an
> >> >> issue
> >> >> triggered by a dump being corrupt. In my case it's this code in
> >> >> kernel.c:cpu_maps_init():
> >> >>
> >> >>     if (*maskptr & (0x1UL << c)) {
> >> >>        cpu = (i * BITS_PER_LONG) + c;
> >> >>        kt->cpu_flags[cpu] |= mapinfo[m].cpu_flag;
> >> >>     }
> >> >>
> >> >> The mask is corrupt, making Crash believe there are more CPU's
> >> >> than the
> >> >> four we have allocated space for in kernel.c:kernel_init. How
> >> >> do you
> >> >> think this should be handled?
> >> >
> >> > Does the "crash --cpus <number> ..." command-line option work
> >> > around it?
> >> >
> >>
> >> Nope, setting "--cpus 2" I still arrive at the code above with
> >>
> >> (gdb) p/x *maskptr
> >> $3 = 0x540dcebf
> >> (gdb)
> >>
> >> As you can see, it's not really a valid cpu mask. Either that or I'm
> >> totally deluded as to the capabilities of the hardware CPU-wise =o)
> >
> > Right, I understand that cpu_maps_init() will still be called, and that
> > kt->cpu_flags will be invalid.  But then what happens?
> >
> 
> Well, it will fill in flags for imagined cpus up to #30, since that's
> the highest bit set in the mask, using those cpu numbers to index into
> a four element large array allocated on the heap, potentially
> overwriting stuff it shouldn't. For me, I never actually got any
> symptoms from it - I just came across it through valgrind while
> investigating the trace extension problem I reported.
> 
> /Per

So then the code should just recognize that the "cpu" value 
is beyond the architecture's maximum array index, report the
inconsistency, and "continue" on to the next map?

Dave