• Mark Rutland's avatar
    arm64: fix dump_backtrace/unwind_frame with NULL tsk · b5e7307d
    Mark Rutland authored
    In some places, dump_backtrace() is called with a NULL tsk parameter,
    e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
    core code. The expectation is that this is treated as if current were
    passed instead of NULL. Similar is true of unwind_frame().
    
    Commit a80a0eb7 ("arm64: make irq_stack_ptr more robust") didn't
    take this into account. In dump_backtrace() it compares tsk against
    current *before* we check if tsk is NULL, and in unwind_frame() we never
    set tsk if it is NULL.
    
    Due to this, we won't initialise irq_stack_ptr in either function. In
    dump_backtrace() this results in calling dump_mem() for memory
    immediately above the IRQ stack range, rather than for the relevant
    range on the task stack. In unwind_frame we'll reject unwinding frames
    on the IRQ stack.
    
    In either case this results in incomplete or misleading backtrace
    information, but is not otherwise problematic. The initial percpu areas
    (including the IRQ stacks) are allocated in the linear map, and dump_mem
    uses __get_user(), so we shouldn't access anything with side-effects,
    and will handle holes safely.
    
    This patch fixes the issue by having both functions handle the NULL tsk
    case before doing anything else with tsk.
    Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
    Fixes: a80a0eb7 ("arm64: make irq_stack_ptr more robust")
    Acked-by: default avatarJames Morse <james.morse@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Yang Shi <yang.shi@linaro.org>
    Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    b5e7307d
traps.c 16.9 KB