kernel panic: n_tty: init_tty

[syzbot]

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.




RAX: ffffffffffffffda RBX: 00000000ffffff9c RCX: 0000000020cf8000
RDX: 000000000000e900 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Kernel panic - not syncing: n_tty: init_tty
CPU: 0 PID: 15643 Comm: syz-executor7 Not tainted 4.14.0-rc5+ #53
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:52
panic+0x1e4/0x417 kernel/panic.c:181
tty_ldisc_init+0x69/0x70 drivers/tty/tty_ldisc.c:830
alloc_tty_struct+0x18b/0x9e0 drivers/tty/tty_io.c:2801
tty_init_dev+0x78/0x4a0 drivers/tty/tty_io.c:1307
ptmx_open+0xf3/0x310 drivers/tty/pty.c:831
chrdev_open+0x257/0x730 fs/char_dev.c:416
do_dentry_open+0x664/0xd40 fs/open.c:752
vfs_open+0x107/0x220 fs/open.c:866
do_last fs/namei.c:3387 [inline]
path_openat+0x1151/0x3520 fs/namei.c:3527
do_filp_open+0x25b/0x3b0 fs/namei.c:3562
do_sys_open+0x502/0x6d0 fs/open.c:1059
C_SYSC_openat fs/open.c:1105 [inline]
compat_SyS_openat+0x2d/0x40 fs/open.c:1103
do_syscall_32_irqs_on arch/x86/entry/common.c:329 [inline]
do_fast_syscall_32+0x3f2/0xf05 arch/x86/entry/common.c:391
entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:124
RIP: 0023:0xf7f8dc79
RSP: 002b:00000000f778901c EFLAGS: 00000296 ORIG_RAX: 0000000000000127
RAX: ffffffffffffffda RBX: 00000000ffffff9c RCX: 0000000020cf8000
RDX: 000000000000e900 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.
Please credit me with: Reported-by: syzbot <syzk...@googlegroups.com>

syzbot will keep track of this bug report.
Once a fix for this bug is committed, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line.

[Greg KH]

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

[Eric Biggers]

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.

Eric

[Dmitry Vyukov]

FTR, answered here:
https://groups.google.com/d/msg/syzkaller-bugs/XxrI4Vje8gA/8pF9WDgoAwAJ

[Dmitry Vyukov]

Filed https://github.com/google/syzkaller/issues/410 for this.
We try to reproduce bugs with failure injection, but somehow we failed
this time.

> But either way, this is a bug;
> panic() is not an acceptable way of handling kmalloc failure.
>
> Eric
>

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20171105220439.GA11631%40zzz.localdomain.
> For more options, visit https://groups.google.com/d/optout.

[Greg KH]

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

[Greg KH]

Ah a big note somewhere saying "We are injecting faults in the system"
might be nice so we can know to ignore them for stuff like startup logic
such as this :)

thanks,

greg k-h

[Eric Biggers]

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().

Eric

[Dmitry Vyukov]

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.

[Alan Cox]

> It's not just running at boot though. It's also being hit by the fuzzer at
> runtime, via ptmx_open().

Then modify the routine to try N_NULL as a follow up (see
tty_ldisc_restore). N_NULL will never fail.

Alan

[syzbot]

syzkaller has found reproducer for the following crash on
2758b3e3e630ba304fc4aca434d591e70e528298

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.

C reproducer is attached
syzkaller reproducer is attached. See https://goo.gl/kgGztJ
for information about syzkaller reproducers


IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by:
syzbot+57840b4d2cc5c469...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00000000004404b9
RDX: 0000000000004000 RSI: 00000000204aeff6 RDI: ffffffffffffff9c
RBP: 0000000000000006 R08: 0000000000000001 R09: 00007fffce210037
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: ffffffffffffffff R14: 6d74702f7665642f R15: 0000000000000004

Kernel panic - not syncing: n_tty: init_tty

CPU: 1 PID: 3157 Comm: syzkaller832190 Not tainted 4.15.0-rc5+ #240

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:

__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
tty_ldisc_init+0x69/0x70 drivers/tty/tty_ldisc.c:831
alloc_tty_struct+0x18b/0xa20 drivers/tty/tty_io.c:2802
tty_init_dev+0x78/0x4a0 drivers/tty/tty_io.c:1308
ptmx_open+0xf3/0x310 drivers/tty/pty.c:832
chrdev_open+0x257/0x730 fs/char_dev.c:417
do_dentry_open+0x667/0xd40 fs/open.c:752
vfs_open+0x107/0x220 fs/open.c:866
do_last fs/namei.c:3379 [inline]
path_openat+0x1151/0x3530 fs/namei.c:3519
do_filp_open+0x25b/0x3b0 fs/namei.c:3554
do_sys_open+0x502/0x6d0 fs/open.c:1059
SYSC_openat fs/open.c:1086 [inline]
SyS_openat+0x30/0x40 fs/open.c:1080
entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x4404b9
RSP: 002b:00007fffce2101a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00000000004404b9
RDX: 0000000000004000 RSI: 00000000204aeff6 RDI: ffffffffffffff9c
RBP: 0000000000000006 R08: 0000000000000001 R09: 00007fffce210037
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: ffffffffffffffff R14: 6d74702f7665642f R15: 0000000000000004

[Tetsuo Handa]

I don't think this is a difficult bug. Why not to fix?

From 7051b364605c65d4266a71c52e5140ca5dbb4ea9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
Date: Thu, 5 Apr 2018 09:42:43 +0900
Subject: [PATCH] tty: Don't call panic() at tty_ldisc_init()

syzbot is reporting kernel panic [1] triggered by memory allocation failure
at tty_ldisc_get() from tty_ldisc_init(). But since both tty_ldisc_get()
and caller of tty_ldisc_init() can cleanly handle errors, tty_ldisc_init()
does not need to call panic() when tty_ldisc_get() failed.

[1] https://syzkaller.appspot.com/bug?id=883431818e036ae6a9981156a64b821110f39187

Signed-off-by: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Jiri Slaby <jsl...@suse.com>
---
drivers/tty/tty_io.c | 5 ++++-
drivers/tty/tty_ldisc.c | 5 +++--
include/linux/tty.h | 2 +-
3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 63114ea..7c838b9 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2816,7 +2816,10 @@ struct tty_struct *alloc_tty_struct(struct tty_driver *driver, int idx)

kref_init(&tty->kref);
tty->magic = TTY_MAGIC;
- tty_ldisc_init(tty);
+ if (tty_ldisc_init(tty)) {
+ kfree(tty);
+ return NULL;
+ }
tty->session = NULL;
tty->pgrp = NULL;
mutex_init(&tty->legacy_mutex);
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 050f4d6..08ddb2c 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -824,12 +824,13 @@ void tty_ldisc_release(struct tty_struct *tty)
* the tty structure is not completely set up when this call is made.
*/

-void tty_ldisc_init(struct tty_struct *tty)
+int tty_ldisc_init(struct tty_struct *tty)
{
struct tty_ldisc *ld = tty_ldisc_get(tty, N_TTY);
if (IS_ERR(ld))
- panic("n_tty: init_tty");
+ return PTR_ERR(ld);
tty->ldisc = ld;
+ return 0;
}

/**
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 47f8af2..1dd587ba 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -701,7 +701,7 @@ static inline int tty_port_users(struct tty_port *port)
extern int tty_set_ldisc(struct tty_struct *tty, int disc);
extern int tty_ldisc_setup(struct tty_struct *tty, struct tty_struct *o_tty);
extern void tty_ldisc_release(struct tty_struct *tty);
-extern void tty_ldisc_init(struct tty_struct *tty);
+extern int __must_check tty_ldisc_init(struct tty_struct *tty);
extern void tty_ldisc_deinit(struct tty_struct *tty);
extern int tty_ldisc_receive_buf(struct tty_ldisc *ld, const unsigned char *p,
char *f, int count);
--
1.8.3.1

[Tetsuo Handa]

OK. Patch is in tty.git#tty-linus as 903f9db10f18f735.

#syz fix: tty: Don't call panic() at tty_ldisc_init()