[lkml]   [2017]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kasan: false use-after-scope warnings with KCOV
On Tue, Nov 28, 2017 at 01:57:49PM +0100, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 1:35 PM, Mark Rutland <> 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

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.


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

 \ /
  Last update: 2017-11-28 15:15    [W:0.092 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site