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