From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751021AbdCQFIV (ORCPT ); Fri, 17 Mar 2017 01:08:21 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:42138 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbdCQFIU (ORCPT ); Fri, 17 Mar 2017 01:08:20 -0400 Date: Fri, 17 Mar 2017 14:08:04 +0900 From: Greg Kroah-Hartman To: Dmitry Vyukov Cc: Jiri Slaby , LKML , Peter Hurley , One Thousand Gnomes , syzkaller Subject: Re: tty: panic in tty_ldisc_restore Message-ID: <20170317050804.GA28075@kroah.com> References: <20170202175559.GB7934@kroah.com> <20170202182342.GB10670@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 13, 2017 at 11:15:29AM +0100, Dmitry Vyukov wrote: > On Thu, Feb 2, 2017 at 7:23 PM, Greg Kroah-Hartman > wrote: > > On Thu, Feb 02, 2017 at 07:03:41PM +0100, Dmitry Vyukov wrote: > >> On Thu, Feb 2, 2017 at 6:55 PM, Greg Kroah-Hartman > >> wrote: > >> > On Thu, Feb 02, 2017 at 06:48:48PM +0100, Dmitry Vyukov wrote: > >> >> Hello, > >> >> > >> >> Syzkaller fuzzer started crashing kernel with the following panics: > >> >> > >> >> Kernel panic - not syncing: Couldn't open N_TTY ldisc for ircomm0 --- error -12. > >> >> CPU: 0 PID: 5637 Comm: syz-executor3 Not tainted 4.9.0 #6 > >> >> Hardware name: Google Google Compute Engine/Google Compute Engine, > >> >> BIOS Google 01/01/2011 > >> >> ffff8801d4ba7a18 ffffffff8234d0df ffffffff00000000 1ffff1003a974ed6 > >> >> ffffed003a974ece 0000000041b58ab3 ffffffff84b38180 ffffffff8234cdf1 > >> >> 0000000000000000 0000000000000000 ffff8801d4ba76a8 00000000dabb4fad > >> >> Call Trace: > >> >> [] __dump_stack lib/dump_stack.c:15 [inline] > >> >> [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 > >> >> [] panic+0x1fb/0x412 kernel/panic.c:179 > >> >> [] tty_ldisc_restore drivers/tty/tty_ldisc.c:520 [inline] > >> >> [] tty_set_ldisc+0x704/0x8b0 drivers/tty/tty_ldisc.c:579 > >> >> [] tiocsetd drivers/tty/tty_io.c:2667 [inline] > >> >> [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924 > >> >> [] vfs_ioctl fs/ioctl.c:43 [inline] > >> >> [] do_vfs_ioctl+0x1bf/0x1630 fs/ioctl.c:679 > >> >> [] SYSC_ioctl fs/ioctl.c:694 [inline] > >> >> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685 > >> >> [] entry_SYSCALL_64_fastpath+0x1f/0xc2 > >> >> > >> >> Kernel panic - not syncing: Couldn't open N_TTY ldisc for ptm2 --- error -12. > >> >> CPU: 0 PID: 7844 Comm: syz-executor0 Not tainted 4.9.0 #6 > >> >> Hardware name: Google Google Compute Engine/Google Compute Engine, > >> >> BIOS Google 01/01/2011 > >> >> ffff8801c3307a18 ffffffff8234d0df ffffffff00000000 1ffff10038660ed6 > >> >> ffffed0038660ece 0000000041b58ab3 ffffffff84b38180 ffffffff8234cdf1 > >> >> 0000000000000000 0000000000000000 ffff8801c33076a8 00000000dabb4fad > >> >> Call Trace: > >> >> [] __dump_stack lib/dump_stack.c:15 [inline] > >> >> [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 > >> >> [] panic+0x1fb/0x412 kernel/panic.c:179 > >> >> [] tty_ldisc_restore drivers/tty/tty_ldisc.c:520 [inline] > >> >> [] tty_set_ldisc+0x704/0x8b0 drivers/tty/tty_ldisc.c:579 > >> >> [] tiocsetd drivers/tty/tty_io.c:2667 [inline] > >> >> [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924 > >> >> [] vfs_ioctl fs/ioctl.c:43 [inline] > >> >> [] do_vfs_ioctl+0x1bf/0x1630 fs/ioctl.c:679 > >> >> [] SYSC_ioctl fs/ioctl.c:694 [inline] > >> >> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685 > >> >> [] entry_SYSCALL_64_fastpath+0x1f/0xc2 > >> >> > >> >> > >> >> In all cases there is a vmalloc failure right before that: > >> >> > >> >> syz-executor4: vmalloc: allocation failure, allocated 0 of 16384 > >> >> bytes, mode:0x14000c2(GFP_KERNEL|__GFP_HIGHMEM), nodemask=(null) > >> >> syz-executor4 cpuset=/ mems_allowed=0 > >> >> CPU: 1 PID: 4852 Comm: syz-executor4 Not tainted 4.9.0 #6 > >> >> Hardware name: Google Google Compute Engine/Google Compute Engine, > >> >> BIOS Google 01/01/2011 > >> >> ffff8801c41df898 ffffffff8234d0df ffffffff00000001 1ffff1003883bea6 > >> >> ffffed003883be9e 0000000041b58ab3 ffffffff84b38180 ffffffff8234cdf1 > >> >> 0000000000000282 ffffffff84fd53c0 ffff8801dae65b38 ffff8801c41df4d0 > >> >> Call Trace: > >> >> [< inline >] __dump_stack lib/dump_stack.c:15 > >> >> [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 > >> >> [] warn_alloc+0x21f/0x360 > >> >> [] __vmalloc_node_range+0x4e9/0x770 > >> >> [< inline >] __vmalloc_node mm/vmalloc.c:1749 > >> >> [< inline >] __vmalloc_node_flags mm/vmalloc.c:1763 > >> >> [] vmalloc+0x5b/0x70 mm/vmalloc.c:1778 > >> >> [] n_tty_open+0x1b/0x470 drivers/tty/n_tty.c:1883 > >> >> [] tty_ldisc_open.isra.3+0x73/0xd0 > >> >> drivers/tty/tty_ldisc.c:463 > >> >> [< inline >] tty_ldisc_restore drivers/tty/tty_ldisc.c:510 > >> >> [] tty_set_ldisc+0x5e4/0x8b0 drivers/tty/tty_ldisc.c:579 > >> >> [< inline >] tiocsetd drivers/tty/tty_io.c:2667 > >> >> [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924 > >> >> [] do_vfs_ioctl+0x1bf/0x1630 > >> >> [< inline >] SYSC_ioctl fs/ioctl.c:698 > >> >> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689 > >> >> [] entry_SYSCALL_64_fastpath+0x1f/0xc2 > >> >> arch/x86/entry/entry_64.S:204 > >> >> > >> >> > >> >> I've found that it's even documented in the source code, but it does > >> >> not look like a good failure mode for allocation failure: > >> >> > >> >> static int n_tty_open(struct tty_struct *tty) > >> >> { > >> >> struct n_tty_data *ldata; > >> >> > >> >> /* Currently a malloc failure here can panic */ > >> >> ldata = vmalloc(sizeof(*ldata)); > >> > > >> > How are you running out of vmalloc() memory? > >> > >> > >> I don't know exactly. But it does not seem to represent a problem for > >> the fuzzer. > >> Is it meant to be very hard to do? > > > > Yes, do you know of any normal way to cause it to fail? > > > Yes. And it turns out that it's actually super-easy to trigger and we > are not running out of memory. > Vmalloc has a check for fatal_signal_pending. So you just invoke > tiocsetd and kill the process concurrently. Machine is down. Sorry for the delay, patches now applied, many thanks for them. greg k-h