Re: kasan: false use-after-scope warnings with KCOV

[Mark Rutland]

On Tue, Nov 28, 2017 at 01:57:49PM +0100, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 1:35 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> > As a heads-up, I'm seeing a number of what appear to be false-positive
> > use-after-scope warnings when I enable both KCOV and KASAN (inline or outline),
> > when using the Linaro 17.08 GCC7.1.1 for arm64. So far I haven't spotted these
> > without KCOV selected, and I'm only seeing these for sanitize-use-after-scope.
> >
> > The reports vary depending on configuration even with the same trigger. I'm not
> > sure if it's the reporting that's misleading, or whether the detection is going
> > wrong.

> > For example, with v4.15-rc1, defconfig + KCOV + KASAN_OUTLINE, I can trigger a
> > splat:
> >
> > $ perf record true

> > [   37.584702] BUG: KASAN: use-after-scope in __alloc_pages_nodemask+0x104/0x1608

> > $ ./scripts/faddr2line vmlinux __alloc_pages_nodemask+0x104/0x1608
> > __alloc_pages_nodemask+0x104/0x1608:
> > __alloc_pages_nodemask at mm/page_alloc.c:4215
> >
> > ... which is the declaration+initialisation of a local variable in
> > __alloc_pages_nodemask:

> > 4215         struct alloc_context ac = { };
> >
> > ... which is clearly not a use-after-scope bug.

> Has anything changed in your environment? Kernel? Compiler? Configs?

This is the first time I've used the Linaro 17.08 GCC 7.1.1
toolchain.

This is also the first time I've tested v4.15-rc1. I had a go with v4.14
(same toolchain, same config), and I saw the same problem.

Previously I was using the Linaro 17.05 GCC 6.3.1 toolchain, which did
not support -fsanitize-use-after-scope.

> The last one that I debugged related to stack false positives was due
> to incorrect DTLB flush after KASAN shadow initialization. But that
> was on x86 and due to a missed backport to 4.4.

The arm64 shadow initialization was recently reworked in v4.15-rc1, but
given I can trigger the same issue on v4.14, it doesn't seem likely
that's the problem.

> Please post disasm of the function. Instrumentation should have been
> cleared shadow for ac in prologue.

The function is 1400+ instructions, so I've just included the prologue
below at the end of the mail.

IIUC the relevant call to __asan_storeN is on line ffff200008293230.

AFAICT, the prologue doesn't zero the shadow at all -- it only
initialises the non-zero bytes. IIRC, functions are meant to clean up
when they return, as we had to fix up for idle in commit:

  0d97e6d8024c71cc ("arm64: kasan: clear stale stack poison")

I tested with idle disabled, which made no difference.

I hacked a kasan_clear_task_stack(current) immediately before the call
to __alloc_pages_nodemask(), and I get a splat later in
__save_stack_trace() instead. So it looks like the shadow placed by
__alloc_pages_nodemask() isn't overlapping its stack variables.

... it looks suspiciously like something is setting up non-zero shadow
bytes, but not zeroing them upon return.

Thanks,
Mark.

---->8----
ffff200008293130 <__alloc_pages_nodemask>:
ffff200008293130:	d116c3ff 	sub	sp, sp, #0x5b0
ffff200008293134:	d2915665 	mov	x5, #0x8ab3                	// #35507
ffff200008293138:	f2a836a5 	movk	x5, #0x41b5, lsl #16
ffff20000829313c:	d2c40007 	mov	x7, #0x200000000000        	// #35184372088832
ffff200008293140:	f2fbffe7 	movk	x7, #0xdfff, lsl #48
ffff200008293144:	f000b666 	adrp	x6, ffff200009962000 <kallsyms_token_index+0x13d00>
ffff200008293148:	a9007bfd 	stp	x29, x30, [sp]
ffff20000829314c:	910003fd 	mov	x29, sp
ffff200008293150:	910543a4 	add	x4, x29, #0x150
ffff200008293154:	910560c6 	add	x6, x6, #0x158
ffff200008293158:	d343fc88 	lsr	x8, x4, #3
ffff20000829315c:	8b070104 	add	x4, x8, x7
ffff200008293160:	a9151ba5 	stp	x5, x6, [x29, #336]
ffff200008293164:	90000005 	adrp	x5, ffff200008293000 <gfp_pfmemalloc_allowed+0x80>
ffff200008293168:	9104c0a5 	add	x5, x5, #0x130
ffff20000829316c:	f90087a8 	str	x8, [x29, #264]
ffff200008293170:	529e4086 	mov	w6, #0xf204                	// #61956
ffff200008293174:	a90153f3 	stp	x19, x20, [sp, #16]
ffff200008293178:	72be5e46 	movk	w6, #0xf2f2, lsl #16
ffff20000829317c:	a9025bf5 	stp	x21, x22, [sp, #32]
ffff200008293180:	aa0303f6 	mov	x22, x3
ffff200008293184:	a90363f7 	stp	x23, x24, [sp, #48]
ffff200008293188:	93407c55 	sxtw	x21, w2
ffff20000829318c:	f90023f9 	str	x25, [sp, #64]
ffff200008293190:	52802234 	mov	w20, #0x111                 	// #273
ffff200008293194:	a90573fb 	stp	x27, x28, [sp, #80]
ffff200008293198:	2a0003fb 	mov	w27, w0
ffff20000829319c:	f900b3a5 	str	x5, [x29, #352]
ffff2000082931a0:	3204d3e5 	mov	w5, #0xf1f1f1f1            	// #-235802127
ffff2000082931a4:	b8276905 	str	w5, [x8, x7]
ffff2000082931a8:	529e5e45 	mov	w5, #0xf2f2                	// #62194
ffff2000082931ac:	72be5e45 	movk	w5, #0xf2f2, lsl #16
ffff2000082931b0:	529e4007 	mov	w7, #0xf200                	// #61952
ffff2000082931b4:	29009486 	stp	w6, w5, [x4, #4]
ffff2000082931b8:	72be5e47 	movk	w7, #0xf2f2, lsl #16
ffff2000082931bc:	29019486 	stp	w6, w5, [x4, #12]
ffff2000082931c0:	9105c3a0 	add	x0, x29, #0x170
ffff2000082931c4:	29029486 	stp	w6, w5, [x4, #20]
ffff2000082931c8:	9113c3bc 	add	x28, x29, #0x4f0
ffff2000082931cc:	29039486 	stp	w6, w5, [x4, #28]
ffff2000082931d0:	91004393 	add	x19, x28, #0x10
ffff2000082931d4:	29049486 	stp	w6, w5, [x4, #36]
ffff2000082931d8:	72a02434 	movk	w20, #0x121, lsl #16
ffff2000082931dc:	29059486 	stp	w6, w5, [x4, #44]
ffff2000082931e0:	29069486 	stp	w6, w5, [x4, #52]
ffff2000082931e4:	29079486 	stp	w6, w5, [x4, #60]
ffff2000082931e8:	29089486 	stp	w6, w5, [x4, #68]
ffff2000082931ec:	29099486 	stp	w6, w5, [x4, #76]
ffff2000082931f0:	52be4006 	mov	w6, #0xf2000000            	// #-234881024
ffff2000082931f4:	290a9487 	stp	w7, w5, [x4, #84]
ffff2000082931f8:	290b9487 	stp	w7, w5, [x4, #92]
ffff2000082931fc:	290c9487 	stp	w7, w5, [x4, #100]
ffff200008293200:	290d9487 	stp	w7, w5, [x4, #108]
ffff200008293204:	290f1487 	stp	w7, w5, [x4, #120]
ffff200008293208:	3204d7e5 	mov	w5, #0xf3f3f3f3            	// #-202116109
ffff20000829320c:	29109486 	stp	w6, w5, [x4, #132]
ffff200008293210:	d000cac4 	adrp	x4, ffff200009bed000 <page_wait_table+0x1280>
ffff200008293214:	b9014fa1 	str	w1, [x29, #332]
ffff200008293218:	913ea099 	add	x25, x4, #0xfa8
ffff20000829321c:	9402f069 	bl	ffff20000834f3c0 <__asan_store4>
ffff200008293220:	52800022 	mov	w2, #0x1                   	// #1
ffff200008293224:	aa1303e0 	mov	x0, x19
ffff200008293228:	d2800301 	mov	x1, #0x18                  	// #24
ffff20000829322c:	b90173a2 	str	w2, [x29, #368]
ffff200008293230:	9402f1ac 	bl	ffff20000834f8e0 <__asan_storeN>
ffff200008293234:	9113c3a2 	add	x2, x29, #0x4f0