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=unavailable 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 C041BC433E0 for ; Tue, 16 Mar 2021 10:03:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 94E4565014 for ; Tue, 16 Mar 2021 10:03:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236311AbhCPKDM (ORCPT ); Tue, 16 Mar 2021 06:03:12 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:37841 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236228AbhCPKCu (ORCPT ); Tue, 16 Mar 2021 06:02:50 -0400 Received: from mail-oi1-f180.google.com ([209.85.167.180]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1M6DSo-1lJvkV34XY-006gYF for ; Tue, 16 Mar 2021 11:02:47 +0100 Received: by mail-oi1-f180.google.com with SMTP id v192so29952080oia.5 for ; Tue, 16 Mar 2021 03:02:47 -0700 (PDT) X-Gm-Message-State: AOAM531n21IrRWgHnkh1mMCl5Z4QeCNkp9pwHtAuLrdR7IMwNQyjz3Lg ML2mi2gUD5bENsoj9DOeDT+SrwC3hPTYKHZRZZY= 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:y9JUqt5bJpWbp5GO62rcqqmFUkOLAcxSn1DwmeHgb5HjAsGLJn8 sgaHjeiv41FLxrKd/uuN/ubtWGaruoijKSJ/Xqgqh5idy7FIipXvrFIY2SDZdLfCmMfyfyU 4qwDYDpjSNSJkpe6C2ZmjCyeLJanS6t6gVwBWZtA27dgFy9FLgmgAT2czOSOeGhqUHCf44y eZyIfSuuPGVCSLD4FmlMw== X-UI-Out-Filterresults: notjunk:1;V03:K0:cDV3J6L76Vo=:w/IaYkw2lW2sdy/QY8cUAB lzJn0wFZQtqNgaHeYapqS193/lV0boNCEEjL5ebz2srPSikFm859ifu4c9tgreUYF7NM0Aq/e gYf0iPoyAgDj9TLLxZOSh7y4JrCu2XwofYmbAM8qgx/niXDVJeL1p6D8pa62ulzgW51Ev5pX1 g5CXCVFUX0O4dFlGGWhbpwvNadrvGCTBZkWwAeStEBd1YmMsePu3Bdsye5VS+IFOXnnGcLMzH qm1n6SUb9F3SV/IPMH2+5JKXLtJWuuiMg0MMLe8WjbPymsFAkuJNf5RaIX+6JEd3deo4SWDC5 Uj0kI4k0oAH+w78CFDM1E/CLrp5Edz7NxVw6RLxL2DbDjbwxt1dYqac8veRHQkaTaAe3PSK+p IYpKiK44dIOkbuCXCEvRdl+Axn9WY2AGihp86tuoZEokA3Qo34iVUV6Xua36y Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 C0A67C433E0 for ; Tue, 16 Mar 2021 10:04:36 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 36CD565018 for ; Tue, 16 Mar 2021 10:04:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36CD565018 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=KCyGVLaB4Hw3pxVT/kP6zhtydeccxS8JlHuTmOX71GY=; b=eBn3USVH7wXKz7l214PPy4wSr yQRzS6z/dqVQED5KGFHQq0SpT09OlweTB4O8pgk4L9OlwSdyxpH5cJ02MJkAxXsX0JhMk3jYIxLlt EhH5WrtDmdfQnLNvfoLCAlc0jFmwLkiVkRJJlsLTx65jd9QC03tKOFq4OwIigXupMNFw6Nk0Q4tTA awAjLveYEIJ6TZiyRKZ8fT9/US8nML8KOppuPZY0smRcz65W5mI8Ci8yXlcd0mR3T5Iu1/BcsBRP1 3H9Bkomd+Bo7SPkkJFh8IZOQySz2fwWaEc2Nezx62putodsYVQSkn+66Jz3GS3CGtaVxqEXp0HpUv uWAYOAKgQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lM6XR-000LYB-Fz; Tue, 16 Mar 2021 10:02:57 +0000 Received: from mout.kundenserver.de ([212.227.126.187]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lM6XL-000LWi-JF for linux-arm-kernel@lists.infradead.org; Tue, 16 Mar 2021 10:02:53 +0000 Received: from mail-oi1-f174.google.com ([209.85.167.174]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MKbPg-1l7t2L04Pk-00L29n for ; Tue, 16 Mar 2021 11:02:49 +0100 Received: by mail-oi1-f174.google.com with SMTP id t83so27535667oih.12 for ; Tue, 16 Mar 2021 03:02:47 -0700 (PDT) X-Gm-Message-State: AOAM532AW0jSRtWAeGKEnt9wmmDQlwRamk+YoagFEUu+PJ/s8Vm+dSoS MfEIKpZZz571JvHgbVz/BMMDNcVl/Q3i/RYYtY8= 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 X-Provags-ID: V03:K1:Dp74ZkR26R4TC4zdJjp9mscY5W2Q24pb23N0eZrzIbJBysU/KR+ lkys2yNJeTd7bePnIZ5MCEFKT2LFDhpsFjArLPATyASClQZ85CW7NG/TrN6E98cl7U/g1u9 5t9DMtyyBEQdWUMbMCzdaMGQ2xz6G3pEcuh5r8eUqO4e8qPy8pw3jXi7jv3smo7/TceaGHU 4JcCedPd6l2DjswNWroUA== X-UI-Out-Filterresults: notjunk:1;V03:K0:QIBAuRJAsJk=:IU26hUwfhrzcPz7P4+rtEL QyZ1U2OzJlRK2NzEK5M/+WVPHNqbA66LvuxLvonj3dnfXbRKmb49QA898dYNvdscwDFjBz22C n+kp+08SEfGAnogdXmlPBzeZaKNlN+kBSRLJl2+45ztxBXJobKI50nJl5BBhcIGNKmDYCzExn BB9g/3nd9z29bjU0XxkQlYC5gz8oIAqaKSGrwrIujBHv0b/8BSminxbmRKDBiSWx0EN/5M0Bb cKI/GDafDPy7d9kVz1o6H+ecQaI3A0NSodU1+1wJMDWJXKh3tZnMAupTuHAqu2fk+G5IR4LFK c7b8/O6R4pyzb5+k2dqwJ0Vs9O+rX5D0omaNxMiutkRgi4ZT+XPflqqmVJBbTQFuinmR234Lw j8stx6lhNrS8gqWH+YSGuvcXh6S67ucTtqj+SDGm3dzvUQ01heAwGFdi6aYZn X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210316_100251_765631_74C177B6 X-CRM114-Status: GOOD ( 25.23 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel