From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758915AbdELVsK (ORCPT ); Fri, 12 May 2017 17:48:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55592 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755256AbdELVsF (ORCPT ); Fri, 12 May 2017 17:48:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 058C280486 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=riel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 058C280486 Message-ID: <1494625675.29205.21.camel@redhat.com> Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode From: Rik van Riel To: Al Viro , Kees Cook Cc: Russell King - ARM Linux , Linus Torvalds , Mark Rutland , Kernel Hardening , Greg KH , Heiko Carstens , LKML , David Howells , Dave Hansen , "H . Peter Anvin" , Ingo Molnar , Pavel Tikhomirov , linux-s390 , the arch/x86 maintainers , Will Deacon , Christian Borntraeger , =?ISO-8859-1?Q?Ren=E9?= Nyffenegger , Catalin Marinas , "Paul E . McKenney" , Peter Zijlstra , Arnd Bergmann , Brian Gerst , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner , Ingo Molnar , "linux-arm-kernel@lists.infradead.org" , Linux API , Oleg Nesterov , Daniel Micay , James Morse , "Eric W . Biederman" , Martin Schwidefsky , Paolo Bonzini , Andrew Morton , Thomas Garnier , "Kirill A . Shutemov" Date: Fri, 12 May 2017 17:47:55 -0400 In-Reply-To: <20170512214144.GT390@ZenIV.linux.org.uk> References: <20170512072802.5a686f23@mschwideX1> <20170512075458.09a3a1ce@mschwideX1> <20170512202106.GO22219@n2100.armlinux.org.uk> <20170512210645.GS390@ZenIV.linux.org.uk> <20170512214144.GT390@ZenIV.linux.org.uk> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 12 May 2017 21:48:04 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-05-12 at 22:41 +0100, Al Viro wrote: > On Fri, May 12, 2017 at 02:17:19PM -0700, Kees Cook wrote: > > > Two things are at risk from stack exhaustion: thread_info (mainly > > addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and > > Really?  Let's take a look at arm, for example: > > struct thread_info { >         unsigned long           flags;          /* low level flags */ >         int                     preempt_count;  /* 0 => preemptable, > <0 => bug */ >         mm_segment_t            addr_limit;     /* address limit */ >         struct task_struct      *task;          /* main task > structure */ > > and current() is defined as current_thread_info()->task. > > Seriously, look at these beasts.  Overwriting ->addr_limit is nowhere > near > the top threat.  If attacker can overwrite thread_info, you have > lost. That is why THREAD_INFO_IN_TASK exists. It moves the struct thread_info to a location away from the stack, which means a stack overflow will not overwrite the thread_info.