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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF8ACC433E0 for ; Tue, 16 Mar 2021 10:02:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2D8EF65018 for ; Tue, 16 Mar 2021 10:02:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D8EF65018 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 84B4A6B006C; Tue, 16 Mar 2021 06:02:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FA836B006E; Tue, 16 Mar 2021 06:02:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 699F96B0070; Tue, 16 Mar 2021 06:02:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id 4D5576B006C for ; Tue, 16 Mar 2021 06:02:51 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 067B018037D35 for ; Tue, 16 Mar 2021 10:02:51 +0000 (UTC) X-FDA: 77925298542.23.D2FEFF7 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by imf06.hostedemail.com (Postfix) with ESMTP id 03699C0007C0 for ; Tue, 16 Mar 2021 10:02:49 +0000 (UTC) Received: from mail-oi1-f181.google.com ([209.85.167.181]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MRT6b-1l1ZVy46tB-00NQJe for ; Tue, 16 Mar 2021 11:02:48 +0100 Received: by mail-oi1-f181.google.com with SMTP id o22so27810242oic.3 for ; Tue, 16 Mar 2021 03:02:47 -0700 (PDT) X-Gm-Message-State: AOAM530GEQhIdGQphGosTLmg5PS4QJuPl485SYslK+miXWd4N8AM8Hbe jf8/BORcltYM2vXLJXUv+sqSNfyWQO2glKOrfIU= X-Google-Smtp-Source: ABdhPJyYZK17O7imUFiCMQCKTR9o6avqVRy81Vy+rKf9jK4uQItjRrZQ+4IBE3PjAG0Gjt7XQmlapzBIrGJRdYy/zMM= X-Received: by 2002:a05:6808:3d9:: with SMTP id o25mr2915607oie.4.1615888966485; Tue, 16 Mar 2021 03:02:46 -0700 (PDT) MIME-Version: 1.0 References: <00000000000069802205bda22b7f@google.com> In-Reply-To: From: Arnd Bergmann Date: Tue, 16 Mar 2021 11:02:29 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [syzbot] kernel panic: corrupted stack end in openat To: Dmitry Vyukov Cc: syzbot , Russell King - ARM Linux , Linus Walleij , Linux ARM , Andrew Morton , LKML , Linux-MM , syzkaller-bugs Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:jTXehL0MeMK9kuaGa+rZ5B2bWphs2tOe8gSLq8M2IZyTG2ay5Gr DFJSH1+TGqnG53VzXaiO8fE6cgl/Rcf/s9+C6uoQB+7lsrLAexepdmVkKHjXCpDihi2q0kT imVDlecKEHUpEHqCoUKCJGAvu6DUzMvMPqtDkFPjtmj/AB4E03V0I2yhBDbUIPR4JhQ0un7 hdh5+/yLM3FRGgxOCwexA== X-UI-Out-Filterresults: notjunk:1;V03:K0:hk7gyfNv9HM=:JNiD4J3A4Z+dVvfrtBILUl Jq/UyoU3M0UOQD1eLjz/w3bkEcO+1IbrOJipfEwQaJwOVzcyJ6Uu97E+ik2dJSARFyrQCjKMw KSRyLMtHZ1qjJTE77LioyUd4la0DFiKpaT/eX+vCzgLgFuckSbvpnH+WxlXMzXp9uFFndPGH9 ufheD23VKjD8gkMA0aSnYt0Bb9ywjSbh5eQWaBaUAc8q0MxxBTGjC+W92Q9iDjE8DPTSvs8BU n+KUcgtvgUclksWFShjej23jm92JufBSKwk2aO+1wmNv3QBjBKd1lNxbuu6uop3epfV7x0Wqt mrHjGPlpGlBMKGQ/cVVhuk1OTo4RKBm5/8vIfbSJPj4pI90iEYoQQMz24S2w3IzMN2tUwxe8A g8VsbkUOSk3hUg6505xslJS0CoVVEfOodeXS9eLoOeYuI8fWmu7XxHSlOKX6H X-Stat-Signature: 1oc7qk5zxtj868kyjwohikor4t3b7ey6 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 03699C0007C0 Received-SPF: none (arndb.de>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mout.kundenserver.de; client-ip=212.227.126.131 X-HE-DKIM-Result: none/none X-HE-Tag: 1615888969-122241 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 16, 2021 at 8:59 AM Dmitry Vyukov wrote: > > On Tue, Mar 16, 2021 at 8:18 AM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 1e28eed1 Linux 5.12-rc3 > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=167535e6d00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=e0cee1f53de33ca3 > > dashboard link: https://syzkaller.appspot.com/bug?extid=0b06ef9b44d00d600183 > > userspace arch: arm > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+0b06ef9b44d00d600183@syzkaller.appspotmail.com > > +arm32 maintainer > I think this is a real stack overflow on arm32, the stack is indeed deep. Nice find. I see there was already a second report, so it seems to be reproducible as well. If you are able to trigger this reliably, you could try printing the frame pointer while unwinding to see what is actually going on: --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -68,8 +68,8 @@ void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long end = frame + 4 + sizeof(struct pt_regs); #ifdef CONFIG_KALLSYMS - printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n", - loglvl, where, (void *)where, from, (void *)from); + printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS), frame %08lx\n", + loglvl, where, (void *)where, from, (void *)from, frame); #else printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n", loglvl, where, from); If that doesn't help, I could have a look at the binary to see which functions in the call chain take a lot of stack space, if any. Which exact compiler version do you use for building these kernels? I can try doing a build with the same commit and config. This one function is one that I have seen before when looking at build warnings with KASAN: > > [<8073772c>] (integrity_kernel_read) from [<8073a904>] (ima_calc_file_hash_tfm+0x178/0x228 security/integrity/ima/ima_crypto.c:484) > > [<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_shash security/integrity/ima/ima_crypto.c:515 [inline]) > > [<8073a78c>] (ima_calc_file_hash_tfm) from [<8073ae2c>] (ima_calc_file_hash+0x124/0x8b8 security/integrity/ima/ima_crypto.c:572) ima_calc_file_hash_tfm() has a SHASH_DESC_ON_STACK(), which by itself can use up 512 bytes, but KASAN sometimes triples this number. However, I see you do not actually have KASAN enabled, so there is probably more to it. Arnd