[Bug 216180] New: KASAN: some memset's are not intercepted

[bugzill...@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216180

Bug ID: 216180
Summary: KASAN: some memset's are not intercepted
Product: Memory Management
Version: 2.5
Kernel Version: ALL
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: enhancement
Priority: P1
Component: Sanitizers
Assignee: mm_san...@kernel-bugs.kernel.org
Reporter: dvy...@google.com
CC: kasa...@googlegroups.com
Regression: No

Created attachment 301283
--> https://bugzilla.kernel.org/attachment.cgi?id=301283&action=edit
.config

syzkaller produced the following report on commit 92f20ff72066:

BUG: unable to handle page fault for address: ffff8880789a6005
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
RIP: 0010:memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:64
Call Trace:
<TASK>
zero_user_segments include/linux/highmem.h:272 [inline]
folio_zero_range include/linux/highmem.h:428 [inline]
truncate_inode_partial_folio+0x76a/0xdf0 mm/truncate.c:237

KASAN should have been intercepted memset, checked the range and produced a
KASAN report with more info.

Is there something special about this memset call?
Does it affect KCSAN/KMSAN?

--
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.

[bugzill...@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216180

--- Comment #1 from Alexander Potapenko (gli...@google.com) ---
When I build the kernel with this config, I can see a call to memset() in
almost the same place in truncate_inode_partial_folio(), and that memset() is
actually the one in mm/kasan/shadow.c

Could it be that KASAN addressability check
(https://elixir.bootlin.com/linux/latest/source/mm/kasan/generic.c#L162)
returned true for the non-existing page?

For posterity, here are the registers from the report:

================================================

RIP: 0010:memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:64

Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab
89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 c3 90 49
89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01
RSP: 0018:ffffc9000547fa90 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000001000 RCX: 0000000000000ffb
RDX: 0000000000000ffb RSI: 0000000000000000 RDI: ffff8880789a6005
RBP: ffffea0001e26980 R08: 0000000000000001 R09: ffff8880789a6005
R10: ffffed100f134dff R11: 0000000000000000 R12: 0000000000000005
R13: 0000000000000000 R14: 0000000000001000 R15: 0000000000000ffb
FS: 00007fd5095b3700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8880789a6005 CR3: 000000005a582000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
================================================

, so it was a call to memset(0xffff8880789a6005, 0x0, 4091)

[bugzill...@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216180

--- Comment #2 from Dmitry Vyukov (dvy...@google.com) ---
This address belongs to physical memory:

ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping
of all physical memory (page_offset_base)

I think addressability check can go wrong for pages that were somehow
unmapped/protected but allocated from page_alloc perspective.


Does KASAN interceptor tail-call memset_erms in this build?
If the interceptor would be in the stack trace, it would be clear that it was
called and no point in filing such reports.

[bugzill...@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216180

--- Comment #3 from Alexander Potapenko (gli...@google.com) ---

> Does KASAN interceptor tail-call memset_erms in this build?

It calls __memset:

ffffffff81c68d30 <memset>:
ffffffff81c68d30: 41 55 push %r13
ffffffff81c68d32: 41 89 f5 mov %esi,%r13d
ffffffff81c68d35: 41 54 push %r12
ffffffff81c68d37: 49 89 d4 mov %rdx,%r12
ffffffff81c68d3a: ba 01 00 00 00 mov $0x1,%edx
ffffffff81c68d3f: 55 push %rbp
ffffffff81c68d40: 48 8b 4c 24 18 mov 0x18(%rsp),%rcx
ffffffff81c68d45: 4c 89 e6 mov %r12,%rsi
ffffffff81c68d48: 48 89 fd mov %rdi,%rbp
ffffffff81c68d4b: e8 30 f8 ff ff call ffffffff81c68580
<kasan_check_range>
ffffffff81c68d50: 84 c0 test %al,%al
ffffffff81c68d52: 74 13 je ffffffff81c68d67
<memset+0x37>
ffffffff81c68d54: 4c 89 e2 mov %r12,%rdx
ffffffff81c68d57: 44 89 ee mov %r13d,%esi
ffffffff81c68d5a: 48 89 ef mov %rbp,%rdi
ffffffff81c68d5d: 5d pop %rbp
ffffffff81c68d5e: 41 5c pop %r12
ffffffff81c68d60: 41 5d pop %r13
ffffffff81c68d62: e9 79 81 5b 02 jmp ffffffff84220ee0
<__memset>
ffffffff81c68d67: 5d pop %rbp
ffffffff81c68d68: 31 c0 xor %eax,%eax
ffffffff81c68d6a: 41 5c pop %r12
ffffffff81c68d6c: 41 5d pop %r13
ffffffff81c68d6e: c3 ret
ffffffff81c68d6f: 90 nop


, which uses an ALTERNATIVE_2 to switch between memset_orig() and
memset_erms():
https://elixir.bootlin.com/linux/latest/source/arch/x86/lib/memset_64.S#L27

[bugzill...@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216180

Dmitry Vyukov (dvy...@google.com) changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID

--- Comment #4 from Dmitry Vyukov (dvy...@google.com) ---
It indeed tail-calls. I guess this can be closed then. Sorry for the noise.