From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933409AbcBYSkL (ORCPT <rfc822;w@1wt.eu>);
	Thu, 25 Feb 2016 13:40:11 -0500
Received: from mail-pa0-f54.google.com ([209.85.220.54]:36250 "EHLO
	mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933151AbcBYSkJ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 25 Feb 2016 13:40:09 -0500
Subject: Re: BUG: unable to handle kernel paging request from pty_write [was:
 Linux 4.4.2]
To: Jiri Slaby <jslaby@suse.cz>, Greg KH <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        torvalds@linux-foundation.org, stable@vger.kernel.org
References: <20160217203730.GA14820@kroah.com> <56CED373.9060603@suse.cz>
Cc: lwn@lwn.net
From: Peter Hurley <peter@hurleysoftware.com>
Message-ID: <56CF4A83.3040408@hurleysoftware.com>
Date: Thu, 25 Feb 2016 10:40:03 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CED373.9060603@suse.cz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 02/25/2016 02:12 AM, Jiri Slaby wrote:
> On 02/17/2016, 09:37 PM, Greg KH wrote:
>> I'm announcing the release of the 4.4.2 kernel.
> ...
>> Peter Hurley (4):
>>       n_tty: Fix unsafe reference to "other" ldisc
>>       tty: Wait interruptibly for tty lock on reopen
>>       tty: Retry failed reopen if tty teardown in-progress
>>       tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)
> 
> It seems like 4.4.2 schedules a tty flush work but the work is deleted
> meanwhile.

Assuming the stack backtrace is accurate, this doesn't look like a freed
work crash.

The process being woken here is a workqueue kworker for the
system_unbound_wq, not the work function being queued.

The crash itself is in try_to_wake_up() (again, assuming the stacktrace is
valid).

Looking at the gs base @ ffff88023fdc0000 which is for CPU7,
rip @ ffff88023fd40000 appears to be in the PERCPU area. You can confirm
this in the kernel log (grep PERCPU) which prints the pcpu base ptr.


> This was trigerred by a gdb build on our servers [1].

I noted that the crash is not strictly for building gdb but appears
to be with gdb running? Perhaps some test that has failed?
Maybe some ABI violation with gdb + kvm?

Is this reproducible?

Regards,
Peter Hurley


> Going to investigate further, if this doesn't ring a bell?
> 
> [1]
> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:I/gdb/standard/x86_64
> 
> kernel tried to execute NX-protected page - exploit attempt? (uid: 399)
> BUG: unable to handle kernel paging request at ffff88023fd40000
> IP: [<ffff88023fd40000>] 0xffff88023fd40000
> PGD 2240067 PUD 23fced063 PMD 23fcee063 PTE 800000023fd40163
> Oops: 0011 [#1] PREEMPT SMP
> Modules linked in: ata_generic ata_piix nls_iso8859_1 nls_cp437 vfat fat
> virtio_rng virtio_blk virtio_pci virtio
> k_ipv6 nf_defrag_ipv6 nf_conntrack btrfs xor raid6_pq reiserfs squashfs
> fuse dm_snapshot dm_bufio dm_mod binfmt_
> misc loop sg
> CPU: 7 PID: 3127 Comm: gdb Not tainted 4.4.2-3-default #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2
> 014
> task: ffff8801e43a4240 ti: ffff8800bb2a4000 task.ti: ffff8800bb2a4000
> RIP: 0010:[<ffff88023fd40000>]  [<ffff88023fd40000>] 0xffff88023fd40000
> RSP: 0018:ffff8800bb2a7c50  EFLAGS: 00056686
> RAX: 00000000bb37e180 RBX: 0000000000000001 RCX: 00000000ffffffff
> RDX: 0000000000000000 RSI: ffff88023fdd6e80 RDI: ffff88023fdd6e80
> RBP: ffffffff810a535a R08: 0000000000000000 R09: 0000000000000020
> R10: 0000000001b52cb0 R11: 0000000000000293 R12: 0000000000000046
> R13: ffff8800bb37e180 R14: 0000000000016e80 R15: ffff8800bb2a7c80
> FS:  00007fe3e4aba740(0000) GS:ffff88023fdc0000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffff88023fd40000 CR3: 00000002353cd000 CR4: 00000000000406e0
> Stack:
>  000000008146e197 ffff88017ee19f00 ffff880234e26a08 ffff88017ed2a830
>  0000000000000005 0000000000010e30 ffff8800bb2a7c90 ffffffff810a5585
>  ffff8800bb2a7cc8 ffffffff81092fe1 0000000000000000 ffff88017ee19f00
> Call Trace:
> Inexact backtrace:
> 
>  [<ffffffff810a5585>] ? wake_up_process+0x15/0x20
>  [<ffffffff81092fe1>] ? insert_work+0x81/0xc0
>  [<ffffffff8109326c>] ? __queue_work+0x24c/0x390
>  [<ffffffff81093947>] ? queue_work_on+0x27/0x40
>  [<ffffffff814732db>] ? tty_flip_buffer_push+0x2b/0x30
>  [<ffffffff81474f1a>] ? pty_write+0x4a/0x60
>  [<ffffffff8146e5c6>] ? n_tty_write+0x1b6/0x4d0
>  [<ffffffff810bd330>] ? __wake_up_sync+0x20/0x20
>  [<ffffffff8146a96b>] ? tty_write+0x1cb/0x2b0
>  [<ffffffff8146e410>] ? n_tty_open+0xe0/0xe0
>  [<ffffffff811fa858>] ? __vfs_write+0x28/0xf0
>  [<ffffffff81334a48>] ? apparmor_file_permission+0x18/0x20
>  [<ffffffff812ff05d>] ? security_file_permission+0x3d/0xc0
>  [<ffffffff811facbf>] ? rw_verify_area+0x4f/0xe0
>  [<ffffffff811faf29>] ? vfs_write+0xa9/0x1a0
>  [<ffffffff811fbb26>] ? SyS_write+0x46/0xa0
>  [<ffffffff816a96f6>] ? entry_SYSCALL_64_fastpath+0x16/0x75
> Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 0
> 00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> RIP  [<ffff88023fd40000>] 0xffff88023fd40000
>  RSP <ffff8800bb2a7c50>
> CR2: ffff88023fd40000
> ---[ end trace 14d86b882766d1bf ]---
> 
> thanks,
>