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,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, 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 D79B1C43461 for ; Mon, 14 Sep 2020 12:52:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A033D206B2 for ; Mon, 14 Sep 2020 12:52:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726596AbgINMwq (ORCPT ); Mon, 14 Sep 2020 08:52:46 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:50020 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726540AbgINMsd (ORCPT ); Mon, 14 Sep 2020 08:48:33 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kHntg-00ABqm-0Z; Mon, 14 Sep 2020 06:47:52 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1kHnte-0002Hj-Mj; Mon, 14 Sep 2020 06:47:51 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Dmitry Vyukov Cc: syzbot , Andrew Morton , Christian Brauner , LKML , Ingo Molnar , Peter Zijlstra , syzkaller-bugs , Thomas Gleixner , Eric Sandeen , Andrey Ryabinin , Alexander Potapenko , kasan-dev References: <00000000000005f0b605af42ab4e@google.com> <87zh5stv04.fsf@x220.int.ebiederm.org> Date: Mon, 14 Sep 2020 07:47:30 -0500 In-Reply-To: (Dmitry Vyukov's message of "Mon, 14 Sep 2020 14:23:01 +0200") Message-ID: <87imcgtti5.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1kHnte-0002Hj-Mj;;;mid=<87imcgtti5.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19LXviMypYNBasGVGCTSKwCdfsubmY84mc= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: KASAN: unknown-crash Read in do_exit X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dmitry Vyukov writes: > On Mon, Sep 14, 2020 at 2:15 PM Eric W. Biederman wrote: >> >> syzbot writes: >> >> > Hello, >> > >> > syzbot found the following issue on: >> >> Skimming the code it appears this is a feature not a bug. >> >> The stack_not_used code deliberately reads the unused/unitiailized >> portion of the stack, to see if that part of the stack was used. >> >> Perhaps someone wants to make this play nice with KASAN? >> >> KASAN should be able to provide better information than reading the >> stack to see if it is still zeroed out. >> >> Eric > > Hi Eric, > > Thanks for looking into this. > > There may be something else in play here. Unused parts of the stack > are supposed to have zero shadow. The stack instrumentation code > assumes that. If there is some garbage left in the shadow (like these > "70 07 00 00 77" in this case), then it will lead to very obscure > false positives later (e.g. some out-of-bounds on stack which can't be > explained easily). > If some code does something like "jongjmp", then we should clear the > stack at the point of longjmp. I think we did something similar for > something called jprobles, but jprobes were removed at some point. > > Oh, wait, the reproducer uses /dev/fb. And as far as I understand > /dev/fd smashes kernel memory left and right. So most likely it's some > wild out of bounds write in /dev/fb. So I am confused. The output in the console does not match the log below. Further the memory addresses in the report don't make a bit of sense. Incrementing by 0x80 and only printing 16 bytes which is 0x10. I am simply responding to the fact that KASAN is complaining about an out of bounds/uniitialized access in stack_not_used. Which seems a legitimate thing to do, but that seems to indicate two debugging primitives are fighting each other. So why we have several very different traces I don't understand. Unless you are right and something is causing corruption. At which point this needs to be delivered to whomever can dig into this. Eric >> > HEAD commit: 729e3d09 Merge tag 'ceph-for-5.9-rc5' of git://github.com/.. >> > git tree: upstream >> > console output: https://syzkaller.appspot.com/x/log.txt?x=170a7cf1900000 >> > kernel config: https://syzkaller.appspot.com/x/.config?x=c61610091f4ca8c4 >> > dashboard link: https://syzkaller.appspot.com/bug?extid=d9ae84069cff753e94bf >> > compiler: gcc (GCC) 10.1.0-syz 20200507 >> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10642545900000 >> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141f2bed900000 >> > >> > Bisection is inconclusive: the issue happens on the oldest tested release. >> > >> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b9ffcd900000 >> > final oops: https://syzkaller.appspot.com/x/report.txt?x=1479ffcd900000 >> > console output: https://syzkaller.appspot.com/x/log.txt?x=1079ffcd900000 >> > >> > IMPORTANT: if you fix the issue, please add the following tag to the commit: >> > Reported-by: syzbot+d9ae84069cff753e94bf@syzkaller.appspotmail.com >> > >> > ================================================================== >> > BUG: KASAN: unknown-crash in stack_not_used include/linux/sched/task_stack.h:101 [inline] >> > BUG: KASAN: unknown-crash in check_stack_usage kernel/exit.c:692 [inline] >> > BUG: KASAN: unknown-crash in do_exit+0x24a6/0x29f0 kernel/exit.c:849 >> > Read of size 8 at addr ffffc9000cf30130 by task syz-executor624/10359 >> > >> > CPU: 1 PID: 10359 Comm: syz-executor624 Not tainted 5.9.0-rc4-syzkaller #0 >> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 >> > Call Trace: >> > __dump_stack lib/dump_stack.c:77 [inline] >> > dump_stack+0x198/0x1fd lib/dump_stack.c:118 >> > print_address_description.constprop.0.cold+0x5/0x497 mm/kasan/report.c:383 >> > __kasan_report mm/kasan/report.c:513 [inline] >> > kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530 >> > stack_not_used include/linux/sched/task_stack.h:101 [inline] >> > check_stack_usage kernel/exit.c:692 [inline] >> > do_exit+0x24a6/0x29f0 kernel/exit.c:849 >> > do_group_exit+0x125/0x310 kernel/exit.c:903 >> > get_signal+0x428/0x1f00 kernel/signal.c:2757 >> > arch_do_signal+0x82/0x2520 arch/x86/kernel/signal.c:811 >> > exit_to_user_mode_loop kernel/entry/common.c:159 [inline] >> > exit_to_user_mode_prepare+0x1ae/0x200 kernel/entry/common.c:190 >> > syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:265 >> > entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> > RIP: 0033:0x446b99 >> > Code: Bad RIP value. >> > RSP: 002b:00007f70f5ed9d18 EFLAGS: 00000246 ORIG_RAX: 0000000000000038 >> > RAX: 0000000000002878 RBX: 00000000006dbc58 RCX: 0000000000446b99 >> > RDX: 9999999999999999 RSI: 0000000000000000 RDI: 0000020002004ffc >> > RBP: 00000000006dbc50 R08: ffffffffffffffff R09: 0000000000000000 >> > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc5c >> > R13: 00007f70f5ed9d20 R14: 00007f70f5ed9d20 R15: 000000000000002d >> > >> > >> > Memory state around the buggy address: >> > ffffc9000cf30000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> > ffffc9000cf30080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> >>ffffc9000cf30100: 00 00 00 00 00 00 70 07 00 00 77 00 00 00 00 00 >> > ^ >> > ffffc9000cf30180: 00 00 70 07 00 00 70 07 00 00 00 00 77 00 70 07 >> > ffffc9000cf30200: 00 70 07 00 77 00 00 00 00 00 70 07 00 00 00 00 >> > ================================================================== >> > >> > >> > --- >> > This report is generated by a bot. It may contain errors. >> > See https://goo.gl/tpsmEJ for more information about syzbot. >> > syzbot engineers can be reached at syzkaller@googlegroups.com. >> > >> > syzbot will keep track of this issue. See: >> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. >> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection >> > syzbot can test patches for this issue, for details see: >> > https://goo.gl/tpsmEJ#testing-patches