linux-kernel - Re: kernel panic: n_tty: init

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]

Date:   Tue, 7 Nov 2017 11:37:30 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        syzbot 
        <bot+57840b4d2cc5c46981d5b9e07c9b7b06d5bcf064@...kaller.appspotmail.com>,
        Jiri Slaby <jslaby@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com
Subject: Re: kernel panic: n_tty: init_tty

On Mon, Nov 6, 2017 at 6:26 PM, Eric Biggers <ebiggers3@...il.com> 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.