From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4F740CD4F21 for ; Wed, 4 Sep 2024 18:31:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DaowE5Bx1yMGXuAuwEjtIwb5FcZ7tmR9iSXy1eLUznw=; b=D+PlmwzDpBSOcEoYfIqnDG05Yv YBm2xVjBzl8VWjQRDIZP94QJ619XdCVFTNc79osan+vnwAt1AGnmFqMWJspKZA2K53FAf403bgNG5 eaPLsEaYZEb0FTHM69kLc8cwWcQztCAGBexohZJ9qLSKQRoCJssC1tIzmy38tLN2syrv5qyK6/CNn E2VHvEpvCUE8JDMlb9u2QV3oJKbpFKgIa2R7QGdA/CoMMZnoZatvN/XHKb98LW4ZnaUhErKd5+83e b9/aTOOph10ChCuj61MKdK6jDpP3YpFtm+cEtzByn88UMp5kS5tEiSdh9krV3LB/EsUfmthpF1MGE N9asvfEg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1slumo-00000005cEy-0urx; Wed, 04 Sep 2024 18:31:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sluiO-00000005any-1RWP for linux-arm-kernel@lists.infradead.org; Wed, 04 Sep 2024 18:26:50 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0EF75FEC; Wed, 4 Sep 2024 11:27:12 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 68F2E3F73F; Wed, 4 Sep 2024 11:26:44 -0700 (PDT) Date: Wed, 4 Sep 2024 19:26:39 +0100 From: Mark Rutland To: Marc Zyngier Cc: Will Deacon , syzbot , catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [arm?] upstream test error: KASAN: invalid-access Write in setup_arch Message-ID: References: <000000000000f362e80620e27859@google.com> <20240830095254.GA7769@willie-the-truck> <86wmjwvatn.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86wmjwvatn.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240904_112648_510707_9919CA6B X-CRM114-Status: GOOD ( 30.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Aug 31, 2024 at 06:52:52PM +0100, Marc Zyngier wrote: > On Fri, 30 Aug 2024 10:52:54 +0100, > Will Deacon wrote: > > > > On Fri, Aug 30, 2024 at 01:35:24AM -0700, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 33faa93bc856 Merge branch kvmarm-master/next into kvmarm-m.. > > > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git fuzzme > > > > +Marc, as this is his branch. > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1398420b980000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=2b7b31c9aa1397ca > > > dashboard link: https://syzkaller.appspot.com/bug?extid=908886656a02769af987 > > > compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 > > > userspace arch: arm64 > > As it turns out, this isn't specific to this branch. I can reproduce > it with this config on a vanilla 6.10 as a KVM guest. Even worse, > compiling with clang results in an unbootable kernel (without any > output at all). > > Mind you, the binary is absolutely massive (130MB with gcc, 156MB with > clang), and I wouldn't be surprised if we were hitting some kind of > odd limit. > > > > > > > Downloadable assets: > > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/384ffdcca292/non_bootable_disk-33faa93b.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/9093742fcee9/vmlinux-33faa93b.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/b1f599907931/Image-33faa93b.gz.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+908886656a02769af987@syzkaller.appspotmail.com > > > > > > Booting Linux on physical CPU 0x0000000000 [0x000f0510] > > > Linux version 6.11.0-rc5-syzkaller-g33faa93bc856 (syzkaller@syzkaller) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #0 SMP PREEMPT now > > > random: crng init done > > > Machine model: linux,dummy-virt > > > efi: UEFI not found. > > > NUMA: No NUMA configuration found > > > NUMA: Faking a node at [mem 0x0000000040000000-0x00000000bfffffff] > > > NUMA: NODE_DATA [mem 0xbfc1d340-0xbfc20fff] > > > Zone ranges: > > > DMA [mem 0x0000000040000000-0x00000000bfffffff] > > > DMA32 empty > > > Normal empty > > > Device empty > > > Movable zone start for each node > > > Early memory node ranges > > > node 0: [mem 0x0000000040000000-0x00000000bfffffff] > > > Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff] > > > cma: Reserved 32 MiB at 0x00000000bba00000 on node -1 > > > psci: probing for conduit method from DT. > > > psci: PSCIv1.1 detected in firmware. > > > psci: Using standard PSCI v0.2 function IDs > > > psci: Trusted OS migration not required > > > psci: SMC Calling Convention v1.0 > > > ================================================================== > > > BUG: KASAN: invalid-access in smp_build_mpidr_hash arch/arm64/kernel/setup.c:133 [inline] > > > BUG: KASAN: invalid-access in setup_arch+0x984/0xd60 arch/arm64/kernel/setup.c:356 > > > Write of size 4 at addr 03ff800086867e00 by task swapper/0 > > > Pointer tag: [03], memory tag: [fe] > > > > > > CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.11.0-rc5-syzkaller-g33faa93bc856 #0 > > > Hardware name: linux,dummy-virt (DT) > > > Call trace: > > > dump_backtrace+0x204/0x3b8 arch/arm64/kernel/stacktrace.c:317 > > > show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324 > > > __dump_stack lib/dump_stack.c:93 [inline] > > > dump_stack_lvl+0x260/0x3b4 lib/dump_stack.c:119 > > > print_address_description mm/kasan/report.c:377 [inline] > > > print_report+0x118/0x5ac mm/kasan/report.c:488 > > > kasan_report+0xc8/0x108 mm/kasan/report.c:601 > > > kasan_check_range+0x94/0xb8 mm/kasan/sw_tags.c:84 > > > __hwasan_store4_noabort+0x20/0x2c mm/kasan/sw_tags.c:149 > > > smp_build_mpidr_hash arch/arm64/kernel/setup.c:133 [inline] > > > setup_arch+0x984/0xd60 arch/arm64/kernel/setup.c:356 > > > start_kernel+0xe0/0xff0 init/main.c:926 > > > __primary_switched+0x84/0x8c arch/arm64/kernel/head.S:243 > > > > > > The buggy address belongs to stack of task swapper/0 > > > > > > Memory state around the buggy address: > > > ffff800086867c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > ffff800086867d00: 00 fe fe 00 00 00 fe fe fe fe fe fe fe fe fe fe > > > >ffff800086867e00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > > > ^ > > > ffff800086867f00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > > > ffff800086868000: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > > > ================================================================== > > > > I can't spot the issue here. We have a couple of fixed-length > > (4 element) arrays on the stack and they're indexed by a simple loop > > counter that runs from 0-3. > > Having trimmed the config to the extreme, I can only trigger the > warning with CONFIG_KASAN_SW_TAGS (CONFIG_KASAN_GENERIC does not > scream). Same thing if I use gcc 14.2.0. Likewise. > However, compiling with clang 14 (Debian clang version 14.0.6) does > *not* result in a screaming kernel, even with KASAN_SW_TAGS. > > So I can see two possibilities here: > > - either gcc is incompatible with KASAN_SW_TAGS and the generic > version is the only one that works > > - or we have a compiler bug on our hands. Looking at this there seem to be a bunch of problems here. I'll try to write this up better tomorrow, but as a holding reply for now, there's definitely a compiler issue and mahybe a kernel issue. Mark.