From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D00610A3D for ; Sat, 31 Aug 2024 17:52:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725126775; cv=none; b=hoGqUgJBLGm/2ix5jN2WmBX2qV8GLczpVb8vD47KnWKMOdHu4ugVCI9mxsiN2/bDc/S8W9CPNNVpDq2zuS09ZwJNkZ4qzCkESQ9yNLKRi424IuviBIeVYVQbXCveDoTdXMMpVt3amAa4OJyTW8arm9QSLRpR6lWAfzvnht+9q+o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725126775; c=relaxed/simple; bh=qXIeDZEytA51QiW9CXiqVlkSKbg0CHzLEiz2qUvN9zU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ukJPNysJ6wWG0fnN/dkHRgBOA7mr1tlIxqGOS6X54bQG4J4OE0XpUUcWs/SVXZdk14sF8r8N8isVy7E5jkEVfSICSCOcsPfIaeI8gEiPJZiarrPumfUFhDPeErGt/Ge/Wgv3BbDJ3fI44SUSfWrGduesPXyzQMuPfQuKTwPbQWU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fXYwDxjZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fXYwDxjZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBF3DC4CEC0; Sat, 31 Aug 2024 17:52:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725126774; bh=qXIeDZEytA51QiW9CXiqVlkSKbg0CHzLEiz2qUvN9zU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fXYwDxjZ/C2vjp9+65ynnBrZ7UTDu5KpF5cpCU+86CSrfieZ95+LD37PBQ6Capc0l BhMXttEHEThLn7TaphcYr6VLyIZ725HJeKMH2ddcY9JVyFHz6MgDJtpmQb0+CCvzZE rYoDn+92iyRwd0vAjHahz1lhjdwkNXBZhdgSM6GiJnuwGwl0Z4b5rq/gegCU4KPn4P H34gzV1fZZykqMl+z/O/GCXlJ+xTbexJOc06MD4J5IqBA/5YJcu2ohEn8/dVOFVjT+ LJsiERJWRTzLU8EastEqrOkVLheTg5zuzEQygQvoQJci6g7ghY66H45nywfR1bqSPS 3ZgfbZKaCzu0g== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1skSHM-008VJP-F8; Sat, 31 Aug 2024 18:52:52 +0100 Date: Sat, 31 Aug 2024 18:52:52 +0100 Message-ID: <86wmjwvatn.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: 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 In-Reply-To: <20240830095254.GA7769@willie-the-truck> References: <000000000000f362e80620e27859@google.com> <20240830095254.GA7769@willie-the-truck> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: will@kernel.org, syzbot+908886656a02769af987@syzkaller.appspotmail.com, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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. 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. Frankly, I can't believe the later, as the code is so daft that I can't imagine gcc getting it *that* wrong. Who knows enough about KASAN to dig into this? M. -- Without deviation from the norm, progress is not possible.