lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171106123309.GA14071@kroah.com>
Date:   Mon, 6 Nov 2017 13:33:09 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     syzbot 
        <bot+57840b4d2cc5c46981d5b9e07c9b7b06d5bcf064@...kaller.appspotmail.com>,
        jslaby@...e.com, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: kernel panic: n_tty: init_tty

On Sun, Nov 05, 2017 at 02:04:39PM -0800, Eric Biggers wrote:
> On Sun, Nov 05, 2017 at 11:34:34AM +0100, Greg KH wrote:
> > On Sun, Nov 05, 2017 at 01:05:02AM -0800, syzbot wrote:
> > > Hello,
> > > 
> > > syzkaller hit the following crash on
> > > b5ac3beb5a9f0ef0ea64cd85faf94c0dc4de0e42
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > > compiler: gcc (GCC) 7.1.1 20170620
> > > .config is attached
> > > Raw console output is attached.
> > 
> > And again, this would be nicer to provide something that I could
> > reproduce this with...
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ