linux-kernel - Re: [PATCH 2/4] ARM: backtrace-clang: add fixup for lr dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAN=-Rxty=Ux5rj-VQSZH-ryj1RiNJvy7mRE7uyx_YAndGtcq7Q@mail.gmail.com>
Date:   Thu, 6 Aug 2020 17:38:46 -0500
From:   Nathan Huckleberry <nhuck15@...il.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Russell King <linux@...linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        clang-built-linux@...glegroups.com,
        Dmitry Safonov <0x7f454c46@...il.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org,
        Lvqiang Huang <lvqiang.huang@...soc.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Miles Chen <miles.chen@...iatek.com>, stable@...r.kernel.org,
        Nathan Huckleberry <nhuck@...gle.com>
Subject: Re: [PATCH 2/4] ARM: backtrace-clang: add fixup for lr dereference

Mostly looks good to me. Just a minor nit.

On Thu, Jul 30, 2020 at 3:51 PM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> If the value of the link register is not correct (tail call from asm
> that didn't set it, stack corruption, memory no longer mapped), then
> using it for an address calculation may trigger an exception.  Without a
> fixup handler, this will lead to a panic, which will unwind, which will
> trigger the fault repeatedly in an infinite loop.
>
> We don't observe such failures currently, but we have. Just to be safe,
> add a fixup handler here so that at least we don't have an infinite
> loop.
>
> Cc: stable@...r.kernel.org
> Fixes: commit 6dc5fd93b2f1 ("ARM: 8900/1: UNWINDER_FRAME_POINTER implementation for Clang")
> Reported-by: Miles Chen <miles.chen@...iatek.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@...gle.com>
> ---
>  arch/arm/lib/backtrace-clang.S | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/lib/backtrace-clang.S b/arch/arm/lib/backtrace-clang.S
> index 5388ac664c12..40eb2215eaf4 100644
> --- a/arch/arm/lib/backtrace-clang.S
> +++ b/arch/arm/lib/backtrace-clang.S
> @@ -146,7 +146,7 @@ for_each_frame:     tst     frame, mask             @ Check for address exceptions
>
>                 tst     sv_lr, #0               @ If there's no previous lr,
>                 beq     finished_setup          @ we're done.
> -               ldr     r0, [sv_lr, #-4]        @ get call instruction
> +prev_call:     ldr     r0, [sv_lr, #-4]        @ get call instruction
>                 ldr     r3, .Lopcode+4
>                 and     r2, r3, r0              @ is this a bl call
>                 teq     r2, r3
> @@ -206,6 +206,13 @@ finished_setup:
>                 mov     r2, frame
>                 bl      printk
>  no_frame:      ldmfd   sp!, {r4 - r9, fp, pc}
> +/*
> + * Accessing the address pointed to by the link register triggered an
> + * exception, don't try to unwind through it.
> + */
> +bad_lr:                mov     sv_fp, #0

It might be nice to emit a warning here since we'll
only hit this case if something fishy is going on
with the saved lr.

> +               mov     sv_lr, #0
> +               b       finished_setup
>  ENDPROC(c_backtrace)
>                 .pushsection __ex_table,"a"
>                 .align  3
> @@ -214,6 +221,7 @@ ENDPROC(c_backtrace)
>                 .long   1003b, 1006b
>                 .long   1004b, 1006b
>                 .long   1005b, 1006b
> +               .long   prev_call, bad_lr
>                 .popsection
>
>  .Lbad:         .asciz  "%sBacktrace aborted due to bad frame pointer <%p>\n"
> --
> 2.28.0.163.g6104cc2f0b6-goog
>

Thanks,
Huck