linux-kernel - Re: BUG: unable to handle kernel paging request from pty

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Feb 2016 10:40:03 -0800
From:	Peter Hurley <peter@...leysoftware.com>
To:	Jiri Slaby <jslaby@...e.cz>, Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, stable@...r.kernel.org
Cc:	lwn@....net
Subject: Re: BUG: unable to handle kernel paging request from pty_write [was:
 Linux 4.4.2]

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,
>