Re: [PATCH] mpparse: prevent table index out-of-bounds

["John Z. Bohach" <jzb@aexorsyst.com>]

On Thursday 06 April 2006 13:18, Randy.Dunlap wrote:
> On Thu, 6 Apr 2006 09:18:45 -0700 John Z. Bohach wrote:
>
> Re: mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module)
> kernel oops)
>
> > I found the root cause, but don't know if its worth fixing.  If the board
> > has more than 32 PCI busses on it, the mptable bus array will overwrite
> > its bounds for the PCI busses, and stomp on anything that's after it.  In
> > this case, what got stomped on is the PAGE_KERNEL_EXEC variable, which
> > changed the bit-field settings for the page tables (cleared the 'present'
> > bit, and screwed up the rest), hence accounting for the page fault.
>
> Well, > 32 busses or just one busid value >= 32.
>
> > This can only happen if there are more than 32 PCI busses, so I'd say its
> > an _extremely_ rare condition on a desktop system.  At any rate, the fix
> > would simply be to change the value of the #define in the mptable.h
> > header file (I forget which exactly, but its easy to find) from 32 to
> > 256. The side effect of that is that the kernel data area would grow, and
> > mostly be a total waste, since I can't fathom a desktop system with more
> > than 32 PCI busses.  On arch's where more than 32 PCI busses are likely,
> > the #define is already 256.
>
> I think that the kernel init code should detect and prevent the
> data corruption.  Here's a patch to do that, by ignoring busses
> whose busid value is too large.

Yeah, I follow your thinking, and was about to do the same thing, until
I consulted the book of armaments, in this case, the MP Spec. ver. 1.4.

Section 4.3.2, Bus Entries, Bus ID:

"An integer that identifies the bus entry.  The BIOS assigns identifiers
starting at zero, sequentially."

Given this, I considered the kernel adequate.  Nevertheless, your patch is a good
defensive programming method against buggy BIOS's.  I haven't actually tested it,
but it looks like it'll be okay.

--john