summaryrefslogtreecommitdiff
path: root/arch/mips/kernel/sync-r4k.c
diff options
context:
space:
mode:
authorAlexander Lobakin <alobakin@pm.me>2022-02-23 01:30:23 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-04-20 09:08:27 +0200
commite7036df78359213bbf104b342a28ba67aba8c9b8 (patch)
treea05d44b8f37a7a38e853cb1dbf3db4ffd4658ac5 /arch/mips/kernel/sync-r4k.c
parent44011dcc079e50bc81108bc02775901117f88e5e (diff)
MIPS: fix fortify panic when copying asm exception handlers
[ Upstream commit d17b66417308996e7e64b270a3c7f3c1fbd4cfc8 ] 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. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'arch/mips/kernel/sync-r4k.c')
0 files changed, 0 insertions, 0 deletions