lkml.org 
[lkml]   [2017]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: kernel panic: n_tty: init_tty
On Mon, Nov 6, 2017 at 6:26 PM, Eric Biggers <ebiggers3@gmail.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.

\
 
 \ /
  Last update: 2017-11-08 21:03    [W:1.151 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site