Re: [PATCH mips-fixes] MIPS: fix fortify panic when copying asm exception handlers

[Thomas Bogendoerfer]

On Wed, Feb 23, 2022 at 01:30:23AM +0000, Alexander Lobakin wrote:
> With KCFLAGS="-O3", I was able to trigger a fortify-source
> memcpy() overflow panic on set_vi_srs_handler().
> Although O3 level is not supported in the mainline, under some
> conditions that may've happened with any optimization settings,
> it's just a matter of inlining luck. The panic itself is correct,
> more precisely, 50/50 false-positive and not at the same time.
> >From the one side, no real overflow happens. Exception handler
> defined in asm just gets copied to some reserved places in the
> memory.
> But the reason behind is that C code refers to that exception
> handler declares it as `char`, i.e. something of 1 byte length.
> It's obvious that the asm function itself is way more than 1 byte,
> so fortify logics thought we are going to past the symbol declared.
> The standard way to refer to asm symbols from C code which is not
> supposed to be called from C is to declare them as
> `extern const u8[]`. This is fully correct from any point of view,
> as any code itself is just a bunch of bytes (including 0 as it is
> for syms like _stext/_etext/etc.), and the exact size is not known
> at the moment of compilation.
> Adjust the type of the except_vec_vi_*() and related variables.
> Make set_handler() take `const` as a second argument to avoid
> cast-away warnings and give a little more room for optimization.
> 
> Fixes: e01402b115cc ("More AP / SP bits for the 34K, the Malta bits and things. Still wants")
> Fixes: c65a5480ff29 ("[MIPS] Fix potential latency problem due to non-atomic cpu_wait.")
> Cc: stable@xxxxxxxxxxxxxxx # 3.10+
> Signed-off-by: Alexander Lobakin <alobakin@xxxxx>
> ---
>  arch/mips/include/asm/setup.h |  2 +-
>  arch/mips/kernel/traps.c      | 22 +++++++++++-----------
>  2 files changed, 12 insertions(+), 12 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]