On 22/05/17 11:32, Daniel Axtens wrote:
Testing the fortified string functions[1] would cause a kernel
panic on boot in test_feature_fixups() due to a buffer overflow
in memcmp.
This boils down to things like this:
extern unsigned int ftr_fixup_test1;
extern unsigned int ftr_fixup_test1_orig;
check(memcmp(&ftr_fixup_test1, &ftr_fixup_test1_orig, size) == 0);
We know that these are asm labels so it is safe to read up to
'size' bytes at those addresses.
However, because we have passed the address of a single unsigned
int to memcmp, the compiler believes the underlying object is in
fact a single unsigned int. So if size > sizeof(unsigned int),
there will be a panic at runtime.
We can fix this by changing the types: instead of calling the asm
labels unsigned ints, call them unsigned int[]s. Therefore the
size isn't incorrectly determined at compile time and we get a
regular unsafe memcmp and no panic.
[1] http://openwall.com/lists/kernel-hardening/2017/05/09/2
Suggested-by: Michael Ellerman <m...@ellerman.id.au>
Cc: Kees Cook <keesc...@chromium.org>
Cc: Daniel Micay <danielmi...@gmail.com>
Signed-off-by: Daniel Axtens <d...@axtens.net>
With this patch on top of Kees' fortify branch, my Tuleta boots
powernv_defconfig baremetal with no obvious regressions.
Tested-by: Andrew Donnellan <andrew.donnel...@au1.ibm.com>
Patch looks sane enough too.
Reviewed-by: Andrew Donnellan <andrew.donnel...@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
