From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750970AbdKSK3c (ORCPT ); Sun, 19 Nov 2017 05:29:32 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:41378 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750927AbdKSK3a (ORCPT ); Sun, 19 Nov 2017 05:29:30 -0500 Date: Sun, 19 Nov 2017 11:29:35 +0100 From: Greg Kroah-Hartman To: Mark Rutland Cc: Catalin Marinas , Ben Hutchings , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Will Deacon Subject: Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit Message-ID: <20171119102935.GE12993@kroah.com> References: <20171106094501.346859822@linuxfoundation.org> <20171106094501.637957117@linuxfoundation.org> <1510599912.18523.8.camel@codethink.co.uk> <20171114135213.nj7lzhhblb5nuxi3@armageddon.cambridge.arm.com> <20171114161756.eumtpoiid6j74o7f@salmiak> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171114161756.eumtpoiid6j74o7f@salmiak> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote: > On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote: > > On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote: > > > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote: > > > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > > > > > ------------------ > > > > > > > > From: Mark Rutland > > > > > > > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream. > > > > > > > > It's possible for a user to deliberately trigger __dump_instr with a > > > > chosen kernel address. > > > > > > > > Let's avoid problems resulting from this by using get_user() rather than > > > > __get_user(), ensuring that we don't erroneously access kernel memory. > > > > > > > > Where we use __dump_instr() on kernel text, we already switch to > > > > KERNEL_DS, so this shouldn't adversely affect those cases. > > > > > > > > Fixes: 60ffc30d5652810d ("arm64: Exception handling") > > > [...] > > > > > > This seems harmless, but I don't think it will fix the bug in 4.4 > > > unless you also cherry-pick: > > > > > > commit c5cea06be060f38e5400d796e61cfc8c36e52924 > > > Author: Mark Rutland > > > Date:   Mon Jun 13 11:15:14 2016 +0100 > > > > > >     arm64: fix dump_instr when PAN and UAO are in use > > > > I agree. In 4.4 dump_instr() doesn't do any checks, just > > set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to > > fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access > > Override"; merged in 4.6), it also makes sense on its own as a security > > improvement for 4.4. > > > > Mark is currently on holiday but he'll follow up next week if any > > patches need back-porting. > > I accidentally glanced at my gmail filter this morning; so I can reply today. > ;) > > I agree that we need both patches. On its own (in the absence of PAN/UAO), > 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we > can dump kernel instructions when we intend to, with 7a7003b1da010d2b > backported. > > Backporting 57f4959bad0a154a as a prerequisite makes sense to me. But that is a "new feature", are you sure about this? So, just apply that one patch and we are all ok? Nothing else? confused, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:41378 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750927AbdKSK3a (ORCPT ); Sun, 19 Nov 2017 05:29:30 -0500 Date: Sun, 19 Nov 2017 11:29:35 +0100 From: Greg Kroah-Hartman To: Mark Rutland Cc: Catalin Marinas , Ben Hutchings , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Will Deacon Subject: Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit Message-ID: <20171119102935.GE12993@kroah.com> References: <20171106094501.346859822@linuxfoundation.org> <20171106094501.637957117@linuxfoundation.org> <1510599912.18523.8.camel@codethink.co.uk> <20171114135213.nj7lzhhblb5nuxi3@armageddon.cambridge.arm.com> <20171114161756.eumtpoiid6j74o7f@salmiak> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171114161756.eumtpoiid6j74o7f@salmiak> Sender: stable-owner@vger.kernel.org List-ID: On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote: > On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote: > > On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote: > > > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote: > > > > 4.4-stable review patch.��If anyone has any objections, please let me know. > > > > > > > > ------------------ > > > > > > > > From: Mark Rutland > > > > > > > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream. > > > > > > > > It's possible for a user to deliberately trigger __dump_instr with a > > > > chosen kernel address. > > > > > > > > Let's avoid problems resulting from this by using get_user() rather than > > > > __get_user(), ensuring that we don't erroneously access kernel memory. > > > > > > > > Where we use __dump_instr() on kernel text, we already switch to > > > > KERNEL_DS, so this shouldn't adversely affect those cases. > > > > > > > > Fixes: 60ffc30d5652810d ("arm64: Exception handling") > > > [...] > > > > > > This seems harmless, but I don't think it will fix the bug in 4.4 > > > unless you also cherry-pick: > > > > > > commit c5cea06be060f38e5400d796e61cfc8c36e52924 > > > Author: Mark Rutland > > > Date:���Mon Jun 13 11:15:14 2016 +0100 > > > > > > ����arm64: fix dump_instr when PAN and UAO are in use > > > > I agree. In 4.4 dump_instr() doesn't do any checks, just > > set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to > > fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access > > Override"; merged in 4.6), it also makes sense on its own as a security > > improvement for 4.4. > > > > Mark is currently on holiday but he'll follow up next week if any > > patches need back-porting. > > I accidentally glanced at my gmail filter this morning; so I can reply today. > ;) > > I agree that we need both patches. On its own (in the absence of PAN/UAO), > 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we > can dump kernel instructions when we intend to, with 7a7003b1da010d2b > backported. > > Backporting 57f4959bad0a154a as a prerequisite makes sense to me. But that is a "new feature", are you sure about this? So, just apply that one patch and we are all ok? Nothing else? confused, greg k-h