On Tue, Nov 07, 2017 at 03:06:53PM +0300, Andrey Ryabinin wrote:
On 11/07/2017 12:39 PM, Fengguang Wu wrote:
Hello,
FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
[ 22.184920] Freeing unused kernel memory: 824K
[ 22.199198] Freeing unused kernel memory: 1436K
[ 22.228460] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 22.230474] rodata_test: all tests were successful
[ 22.254830]
==================================================================
[ 22.257125] BUG: KASAN: slab-out-of-bounds in copyin+0xea/0x170
[ 22.258648] Write of size 26 at addr ffff880013432540 by task init/1
[ 22.260272]
It says that we write 26 bytes starting from ffff880013432540.
But according to the dump of shadow memory:
[ 22.297667] >ffff880013432500: fc fc fb fb fb fb fc fc 00 00 00 03 fc fc fb
fb
[ 22.298581] ^
we have allocated 27 bytes at address stating from ffff880013432540.
So this looks like a false positive. I've seen reports like this before:
https://lkml.kernel.org/r/<[email protected]>
https://lkml.kernel.org/r/<[email protected]>
This happens only on old gcc versions, in your case it's 4.6:
[ 0.000000] Linux version 4.14.0-rc8 (kbuild@lkp-wsx01) (gcc version 4.6.4
(Debian 4.6.4-7)) #14 SMP PREEMPT Tue Nov 7 06:50:21 CST 2017
Old GCC is misscompiling something in check_memory_region() which cause
false-positive like this one.
I never bothered to dig it deeper, because I've never seen this with GCC versions
(>= 4.9.2) that actually support KASAN.
It's almost pointless to use KASAN=y kernel built with old GCC. All memory
accesses, except manually instrumented with kasan_check_[read|write](),
won't be checked.
Good point! I'll disable KASAN in pre-4.9.2 gcc versions.
Thanks,
Fengguang
