Received: by 10.223.164.202 with SMTP id h10csp943857wrb; Tue, 7 Nov 2017 18:09:07 -0800 (PST) X-Google-Smtp-Source: ABhQp+S5a2RT4dmusEVTFFlmtfx2mG8JmCrvMnAaZkkn9eqM+BZBFPeAfzJGgSWF4RNPspS2T2Uc X-Received: by 10.99.182.14 with SMTP id j14mr711357pgf.116.1510106947288; Tue, 07 Nov 2017 18:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510106947; cv=none; d=google.com; s=arc-20160816; b=Jjb19LU9aRhvj5xzRI5DertCViIqkdTuU7GBJBGXwhp9sOvj4CriiJr1iz+7QRVyYE Ug6RdZ6OnBwW9PNjB6yFNHs/2478rQys/4WRwbHYON2gbSI4KwM7SW3UPmx7b0N9RgKz +s1SZufL5frZlHvF943HxTQbydNF0GlEHBEn3go7uWdZmnb6SbthXzhBz0zE0+WmiL2u JALE/HtEXF+Yb7OVJW26zo8I5mJvGpK7REusA/zKOcMiuAy9i8d9iii9hcvkewYLRrxQ +S/EFMRd9O4aL40M8enCAU68z9Hm8f6DyhvrPGsaK/BaJOLJakfKioHlRV+F5gQ6WO5g +YGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject:dmarc-filter :arc-authentication-results; bh=eL41nkePuzLzxH3klKcLjbhONlirJljllfwEzDKoe5c=; b=fQ/6fCQJ5XVHNpykiN5mr+QA0yzquhnPkE1Z9XzF3Po6tSGu7hRNyTvokpnhwN0hm+ mcoki2JpqR35tFRmrdFamHAxyMtmSlGwqKFbEZOShwpN2sqsuCsHR0gZfISbTE/XKtJu ABEYkR8buiRcpRfa8X1KDL3i1YcbM9QQiBebcNuUbaUIjDHLmjWQyXzHy5ginqXcpJKe nj2KJqF6/W5q1eFC1s0HFwt050eUBlmiSTueBpGE41Z5L0QM7a1V4YoarN02uWh/6jzA Uhf8DfPVwjS1iGprav7doDIxY+NwDLyer3bljgyEue6K4vIhQIhgKuNfFl2BgbNpu9d3 hBig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l17si2528799pgn.507.2017.11.07.18.08.54; Tue, 07 Nov 2017 18:09:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754085AbdKGRoj (ORCPT + 91 others); Tue, 7 Nov 2017 12:44:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56704 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753909AbdKGRoh (ORCPT ); Tue, 7 Nov 2017 12:44:37 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 74632624CD; Tue, 7 Nov 2017 17:44:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 74632624CD Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=david@redhat.com Received: from [10.36.116.111] (ovpn-116-111.ams2.redhat.com [10.36.116.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id D327360C8D; Tue, 7 Nov 2017 17:44:34 +0000 (UTC) Subject: Re: WARNING in do_debug To: Dmitry Vyukov , syzbot Cc: LKML , syzkaller-bugs@googlegroups.com, KVM list , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Haozhong Zhang , Thomas Gleixner , Ingo Molnar References: <001a113f83b2b3b8b8055cd621f3@google.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <72db2141-3f24-f209-1df0-0d801e3ac4bc@redhat.com> Date: Tue, 7 Nov 2017 18:44:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 07 Nov 2017 17:44:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31.10.2017 12:47, Dmitry Vyukov wrote: > On Tue, Oct 31, 2017 at 2:34 PM, syzbot > > wrote: >> Hello, >> >> syzkaller hit the following crash on >> 0787643a5f6aad1f0cdeb305f7fe492b71943ea4 >> 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. >> >> syzkaller reproducer is attached. See https://goo.gl/kgGztJ >> for information about syzkaller reproducers >> >> >> ------------[ cut here ]------------ >> WARNING: CPU: 0 PID: 3045 at arch/x86/kernel/traps.c:776 >> cond_local_irq_disable arch/x86/kernel/traps.c:85 [inline] >> WARNING: CPU: 0 PID: 3045 at arch/x86/kernel/traps.c:776 >> do_debug+0x4d8/0x6e0 arch/x86/kernel/traps.c:790 >> Kernel panic - not syncing: panic_on_warn set ... >> >> CPU: 0 PID: 3045 Comm: syz-executor6 Not tainted 4.14.0-rc5+ #142 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> Call Trace: >> <#DB> >> __dump_stack lib/dump_stack.c:16 [inline] >> dump_stack+0x194/0x257 lib/dump_stack.c:52 >> panic+0x1e4/0x417 kernel/panic.c:181 >> __warn+0x1c4/0x1d9 kernel/panic.c:542 >> report_bug+0x211/0x2d0 lib/bug.c:183 >> fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178 >> do_trap_no_signal arch/x86/kernel/traps.c:212 [inline] >> do_trap+0x260/0x390 arch/x86/kernel/traps.c:261 >> do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298 >> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311 >> invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905 >> RIP: 0010:cond_local_irq_disable arch/x86/kernel/traps.c:85 [inline] >> RIP: 0010:do_debug+0x4d8/0x6e0 arch/x86/kernel/traps.c:790 >> RSP: 0018:ffff8801db20fe98 EFLAGS: 00010246 >> RAX: dffffc0000000000 RBX: ffff8801db20ff58 RCX: 0000000000000000 >> RDX: 1ffff1003b641ffc RSI: 0000000000000001 RDI: ffffffff85ac6398 >> RBP: ffff8801db20ff48 R08: ffff8801db20ffe8 R09: 0000000000000000 >> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000004001 >> R13: ffff8801cd8541c0 R14: 1ffff1003b641fd8 R15: 0000000000004000 >> debug+0x34/0x70 arch/x86/entry/entry_64.S:1056 >> RIP: 0010:copy_user_enhanced_fast_string+0xe/0x20 >> arch/x86/lib/copy_user_64.S:180 >> RSP: 0018:ffff8801cd2cfe68 EFLAGS: 00010246 >> RAX: ffffed0039a59fe1 RBX: 0000000020000000 RCX: 000000000000003f >> RDX: 0000000000000040 RSI: 0000000020000001 RDI: ffff8801cd2cfec9 >> RBP: ffff8801cd2cfe98 R08: ffffed0039a59fe1 R09: ffffed0039a59fe1 >> R10: 0000000000000008 R11: ffffed0039a59fe0 R12: 0000000000000040 >> R13: ffff8801cd2cfec8 R14: 00007ffffffff000 R15: 0000000020000040 >> >> copy_from_user include/linux/uaccess.h:146 [inline] >> SYSC_timer_create kernel/time/posix-timers.c:579 [inline] >> SyS_timer_create+0x89/0x120 kernel/time/posix-timers.c:572 >> entry_SYSCALL_64_fastpath+0x1f/0xbe >> RIP: 0033:0x452719 >> RSP: 002b:00007f906f324be8 EFLAGS: 00000212 ORIG_RAX: 00000000000000de >> RAX: ffffffffffffffda RBX: 0000000000758020 RCX: 0000000000452719 >> RDX: 0000000020000000 RSI: 0000000020000000 RDI: ffffffffffffffff >> RBP: 0000000000000082 R08: 0000000000000000 R09: 0000000000000000 >> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f3cf8 >> R13: 00000000ffffffff R14: 00007f906f3256d4 R15: 0000000000000000 >> Dumping ftrace buffer: >> (ftrace buffer empty) >> Kernel Offset: disabled >> Rebooting in 86400 seconds.. > > > I think this is kvm bug, so +kvm maintainers. > > Unfortunately, this does not reproduce with a C program. But I was > able to easily reproduce it with the provided syzkaller program by > running: > ./syz-execprog repro.txt > > On upstream 15f859ae5c43c7f0a064ed92d33f7a5bc5de6de0 (Oct 26). > Seems that guest somehow sets debug register contents for host: The BUG is triggered due to dr6 being set to DR_STEP. In kvm, we only restore dr6 (via hw_breakpoint_restore()) in case hw breakpoints are active (hw_breakpoint_active()). However I am getting the feeling that we should restore dr6 unconditionally to current->thread.debugreg6 (as it doesn't seem to be related to hw breakpoints only). The question would then be, when we have to restore it (maybe its already too late at that point?). (no expert on x86 debug regs (yet)). -- Thanks, David / dhildenb From 1582773659241202310@xxx Tue Oct 31 11:49:47 +0000 2017 X-GM-THRID: 1582772793279943434 X-Gmail-Labels: Inbox,Category Forums