• Thomas Gleixner's avatar
    genirq: Prevent access beyond allocated_irqs bitmap · c1ee6264
    Thomas Gleixner authored
    Lars-Peter Clausen pointed out:
    
       I stumbled upon this while looking through the existing archs using
       SPARSE_IRQ.  Even with SPARSE_IRQ the NR_IRQS is still the upper
       limit for the number of IRQs.
    
       Both PXA and MMP set NR_IRQS to IRQ_BOARD_START, with
       IRQ_BOARD_START being the number of IRQs used by the core.
    
       In various machine files the nr_irqs field of the ARM machine
       defintion struct is then set to "IRQ_BOARD_START + NR_BOARD_IRQS".
    
       As a result "nr_irqs" will greater then NR_IRQS which then again
       causes the "allocated_irqs" bitmap in the core irq code to be
       accessed beyond its size overwriting unrelated data.
    
    The core code really misses a sanity check there.
    
    This went unnoticed so far as by chance the compiler/linker places
    data behind that bitmap which gets initialized later on those affected
    platforms.
    
    So the obvious fix would be to add a sanity check in early_irq_init()
    and break all affected platforms. Though that check wants to be
    backported to stable as well, which will require to fix all known
    problematic platforms and probably some more yet not known ones as
    well. Lots of churn.
    
    A way simpler solution is to allocate a slightly larger bitmap and
    avoid the whole churn w/o breaking anything. Add a few warnings when
    an arch returns utter crap.
    Reported-by: default avatarLars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Cc: stable@kernel.org # .37
    Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
    Cc: Eric Miao <eric.y.miao@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    c1ee6264
resend.c 2.03 KB