kern/46872: mtrr_i686.c may access uninitialized data

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

>Number:         46872
>Category:       kern
>Synopsis:       mtrr_i686.c may access uninitialized data
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 29 14:35:00 +0000 2012
>Originator:     Wolfgang Stukenbrock
>Release:        NetBSD 5_1_STABLE - current is affected too
>Organization:
Dr. Nagler & Company GmbH
>Environment:
        
        
System: NetBSD test-s0 4.0 NetBSD 4.0 (NSW-WS) #0: Tue Aug 17 17:28:09 CEST 
2010 wgstuken@test-s0:/usr/src/sys/arch/amd64/compile/NSW-WS amd64
Architecture: x86_64
Machine: amd64
>Description:
        The kernel uses a static allocated array "mttr_raw[]" that is 
initialized with some default values.
        In i686_mtrr_init_first() the message is printed if the actual CPU has 
more MTRR's as supported.
        In i686_raw2soft() there is a loop with the actual number of MTRR's 
that accesses an allocated array
        of the correct size, but it also accesses "mttr_raw[]" via the pointer 
"mtrr_var_raw" that is initialized
        with "mtrr_var_raw = &mtrr_raw[0];"
        If there are more MTRR's as supported, the "other" entries in 
"mttr_raw[]" are accesed or if there are much
        more MTRR's, we access memory behind the array.
        I've not looked if there are even more places where this happens.
>How-To-Repeat:
        I've a crash during boot and saw the messages that there are too much 
MTRR's for the kernel.
        Then I've looked into the sources. I do not know if this is related or 
not, but it is a bug in any case.
>Fix:
        Not known, because I do not know much about the MTRR's - sorry.
        If possible, eliminate the static array and do a complete dynamic 
initialisation. A comment in mttr.h assumes,
        that there may be up to 255 MTRR's on a CPU.

>Unformatted: