From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756949AbdKGKhy (ORCPT ); Tue, 7 Nov 2017 05:37:54 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:51754 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756936AbdKGKhw (ORCPT ); Tue, 7 Nov 2017 05:37:52 -0500 X-Google-Smtp-Source: ABhQp+T38LznfWvX8D0re4O8cuPH8tYd+noCTJEvNLZ+50pijeLVnWVtyut3VBDDyh6UElXhXqJjoCUI5fftyuC4Njk= MIME-Version: 1.0 In-Reply-To: <20171106172604.GB50562@gmail.com> References: <94eb2c0630b4161a5e055d38a2e3@google.com> <20171105103434.GC1487@kroah.com> <20171105220439.GA11631@zzz.localdomain> <20171106123309.GA14071@kroah.com> <20171106172604.GB50562@gmail.com> From: Dmitry Vyukov Date: Tue, 7 Nov 2017 11:37:30 +0100 Message-ID: Subject: Re: kernel panic: n_tty: init_tty To: Eric Biggers Cc: Greg KH , syzbot , Jiri Slaby , LKML , syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 6, 2017 at 6:26 PM, Eric Biggers wrote: > On Mon, Nov 06, 2017 at 01:33:09PM +0100, Greg KH wrote: >> > >> > I just saw the same crash running syzkaller. It was preceded by a fault >> > injection in tty_ldisc_get() here: >> > >> > ld = kmalloc(sizeof(struct tty_ldisc), GFP_KERNEL); >> > if (ld == NULL) { >> > put_ldops(ldops); >> > return ERR_PTR(-ENOMEM); >> > } >> > >> > So then it panics at: >> > >> > if (IS_ERR(ld)) >> > panic("n_tty: init_tty"); >> > >> > It seems that syzkaller needs to do a better job reproducing and reporting bugs >> > that are only reproducible with fault injection. But either way, this is a bug; >> > panic() is not an acceptable way of handling kmalloc failure. >> >> That's a well-known issue, it's pretty much impossible to unwind safely >> from here. If you don't have enough memory at boot to get a tty_ldisc, >> you have bigger problems. >> >> thanks, >> >> greg k-h > > It's not just running at boot though. It's also being hit by the fuzzer at > runtime, via ptmx_open(). Correct. An untrusted user can do this at any time. And provoke the kmalloc failure with a memory-restricted container. I bet one can cook a program in few hours that instantly kills any linux in existence. Is it really pretty much impossible to unwind safely from here? I thought that it's just a problem with the current implementation, design of which makes it hard to handle this correctly. Because kernel handles hundreds of resources (incl hardware) in, I think, very similar situations.