Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752028AbdHVRvY (ORCPT ); Tue, 22 Aug 2017 13:51:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59556 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbdHVRvX (ORCPT ); Tue, 22 Aug 2017 13:51:23 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AF9C8404321 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Tue, 22 Aug 2017 12:51:16 -0500 From: Josh Poimboeuf To: yang oliver Cc: "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "luto@kernel.org" , "x86@kernel.org" , "rostedt@goodmis.org" , "linux-kernel@vger.kernel.org" , Yong Yang Subject: Re: [PATCH] x86/nmi/64: avoid passing user space rsp of pt_regs to nmi handler Message-ID: <20170822175115.k3tdjlkltua7lkiu@treble> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 22 Aug 2017 17:51:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 674 Lines: 16 On Tue, Aug 22, 2017 at 05:09:19PM +0000, yang oliver wrote: > From: Yong Yang > > While NMI interrupts the very beginning of SYSCALL, the rsp could > be still user space address without loading kernel address. Then > the pt_regs constructed by the NMI entry point could have a user > space rsp. If a NMI handler tried to dump stack by using this rsp, > it can cause the kernel panic. To me this sounds like an unwinder bug. The unwinder is supposed to have checks to prevent it from accessing user space. I know you had previously reported this for an older (pre-4.9) kernel. Have you verified the bug still exists on a recent kernel? -- Josh