From: Matt Fleming <matt@readmodwrite.com>
To: Uros Bizjak <ubizjak@gmail.com>, Ingo Molnar <mingo@kernel.org>
Cc: Jakub Jelinek <jakub@redhat.com>,
linux-kernel@vger.kernel.org, kernel-team@cloudflare.com,
Matt Fleming <matt@readmodwrite.com>
Subject: CONFIG_KASAN triggers ASAN bug in GCC 13.3.0 and 14.1.0
Date: Fri, 13 Dec 2024 19:01:19 +0000 [thread overview]
Message-ID: <20241213190119.3449103-1-matt@readmodwrite.com> (raw)
Hi everyone,
I've run into following Oops when running with KASAN enabled:
[ 22.938710][ T0] Oops: general protection fault, probably for non-canonical address 0xdffffc00000087c8: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ 22.939369][ T0] KASAN: probably user-memory-access in range [0x0000000000043e40-0x0000000000043e47]
[ 22.939369][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.1-cloudflare-kasan-2024.11.20 #1
[ 22.939369][ T0] Hardware name: MACHINE, BIOS VERSION 09/04/2024
[ 22.939369][ T0] RIP: 0010:switch_mm_irqs_off+0x43/0xd70
[ 22.939369][ T0] Code: 48 83 ec 20 48 c7 c0 40 3e 04 00 65 48 8b 1d 14 41 91 77 48 ba 00 00 00 00 00 fc ff df 65 44 0f b7 25 11 41 91 77 48 c1 e8 03 <0f> b6 04 10 84 c0 74 06 0f 8e be 09 00 00 65 44 0f b6 2d a6 41 91
[ 22.939369][ T0] RSP: 0000:ffffffff8ce07e00 EFLAGS: 00010012
[ 22.939369][ T0] RAX: 00000000000087c8 RBX: ffffffff8d20a740 RCX: 0000001850076000
[ 22.939369][ T0] RDX: dffffc0000000000 RSI: ffffffff8d7a28c0 RDI: 0000000000000000
[ 22.939369][ T0] RBP: ffffffff8d7a28c0 R08: 00000000aa299018 R09: e4977f26b7bc541a
[ 22.939369][ T0] R10: ffffffff8ce07e00 R11: 8000000000000063 R12: 0000000000000000
[ 22.939369][ T0] R13: 0000001850076000 R14: 0000000000000000 R15: ffff889850076000
[ 22.939369][ T0] FS: 0000000000000000(0000) GS:ffff8887efa00000(0000) knlGS:0000000000000000
[ 22.939369][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 22.939369][ T0] CR2: ffff88c04f1ff000 CR3: 00000037f4852001 CR4: 0000000000770ef0
[ 22.939369][ T0] PKRU: 55555554
[ 22.939369][ T0] Call Trace:
[ 22.939369][ T0] <TASK>
[ 22.939369][ T0] ? __die_body.cold+0x19/0x21
[ 22.939369][ T0] ? die_addr+0x46/0x70
[ 22.939369][ T0] ? exc_general_protection+0x119/0x210
[ 22.939369][ T0] ? asm_exc_general_protection+0x26/0x30
[ 22.939369][ T0] ? switch_mm_irqs_off+0x43/0xd70
[ 22.939369][ T0] ? __pfx_efi_memmap_init_late+0x10/0x10
[ 22.939369][ T0] switch_mm+0x14/0x20
[ 22.939369][ T0] efi_set_virtual_address_map+0x75/0x180
[ 22.939369][ T0] ? srso_alias_return_thunk+0x5/0xfbef5
[ 22.939369][ T0] efi_enter_virtual_mode+0x6fb/0x7c0
[ 22.939369][ T0] ? alt_reloc_selftest+0x1f/0x50
[ 22.939369][ T0] start_kernel+0x323/0x3a0
[ 22.939369][ T0] x86_64_start_reservations+0x24/0x30
[ 22.939369][ T0] x86_64_start_kernel+0x7f/0x80
[ 22.939369][ T0] common_startup_64+0x13e/0x141
[ 22.939369][ T0] </TASK>
This was supposed to be fixed by the compiler version check in
f61f02d1ff78 ("x86/percpu: Re-enable named address spaces with KASAN for
GCC 13.3+"), but I'm still able to trigger this problem with both GCC
14.1.0 and GCC 13.3.0 which include fixes for PR sanitizer/111736.
(Reverting f61f02d1ff78 obviously prevents the oops)
Here's the assembly that shows the ASAN protection kicking in for the
per-CPU addresses (cpu_tlbstate):
ffffffff8112fc40 <switch_mm_irqs_off>:
ffffffff8112fc40: f3 0f 1e fa endbr64
ffffffff8112fc44: e8 e7 79 fd ff call ffffffff81107630 <__fentry__>
ffffffff8112fc49: 41 57 push %r15
ffffffff8112fc4b: 41 56 push %r14
ffffffff8112fc4d: 49 89 d6 mov %rdx,%r14
ffffffff8112fc50: 41 55 push %r13
ffffffff8112fc52: 41 54 push %r12
ffffffff8112fc54: 55 push %rbp
ffffffff8112fc55: 48 89 f5 mov %rsi,%rbp
ffffffff8112fc58: 53 push %rbx
ffffffff8112fc59: 48 83 ec 20 sub $0x20,%rsp
ffffffff8112fc5d: 48 c7 c0 40 3e 04 00 mov $0x43e40,%rax
ffffffff8112fc64: 65 48 8b 1d 14 41 f1 mov %gs:0x7ef14114(%rip),%rbx # 43d80 <cpu_tlbstate>
ffffffff8112fc6b: 7e
ffffffff8112fc6c: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx
ffffffff8112fc73: fc ff df
ffffffff8112fc76: 65 44 0f b7 25 11 41 movzwl %gs:0x7ef14111(%rip),%r12d # 43d90 <cpu_tlbstate+0x10>
ffffffff8112fc7d: f1 7e
ffffffff8112fc7f: 48 c1 e8 03 shr $0x3,%rax
ffffffff8112fc83: 0f b6 04 10 movzbl (%rax,%rdx,1),%eax
Fault occurs here due to ASAN -----------^
Anyone got any ideas how to debug this further?
next reply other threads:[~2024-12-13 19:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-13 19:01 Matt Fleming [this message]
2024-12-14 1:17 ` CONFIG_KASAN triggers ASAN bug in GCC 13.3.0 and 14.1.0 Uros Bizjak
2024-12-16 16:20 ` Matt Fleming
2024-12-16 16:56 ` Uros Bizjak
2025-02-27 12:22 ` Ingo Molnar
2025-02-27 12:30 ` Uros Bizjak
2025-02-27 12:46 ` Ingo Molnar
2025-02-27 13:35 ` Uros Bizjak
2025-02-27 18:27 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241213190119.3449103-1-matt@readmodwrite.com \
--to=matt@readmodwrite.com \
--cc=jakub@redhat.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=ubizjak@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.