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

[Per Fransson]

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

> Dave
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility