lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20241213190119.3449103-1-matt@readmodwrite.com>
Date: Fri, 13 Dec 2024 19:01:19 +0000
From: Matt Fleming <matt@...dmodwrite.com>
To: Uros Bizjak <ubizjak@...il.com>,
	Ingo Molnar <mingo@...nel.org>
Cc: Jakub Jelinek <jakub@...hat.com>,
	linux-kernel@...r.kernel.org,
	kernel-team@...udflare.com,
	Matt Fleming <matt@...dmodwrite.com>
Subject: CONFIG_KASAN triggers ASAN bug in GCC 13.3.0 and 14.1.0

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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ