diff for duplicates of <1494625675.29205.21.camel@redhat.com> diff --git a/a/content_digest b/N1/content_digest index b0bb741..731cf80 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -31,27 +31,7 @@ Will Deacon <will.deacon@arm.com> Christian Borntraeger <borntraeger@de.ibm.com> " Ren\303\251 Nyffenegger <mail@renenyffenegger.ch>" - Catalin Marinas <catalin.marinas@arm.com> - Paul E . McKenney <paulmck@linux.vnet.ibm.com> - Peter Zijlstra <a.p.zijlstra@chello.nl> - Arnd Bergmann <arnd@arndb.de> - Brian Gerst <brgerst@gmail.com> - Borislav Petkov <bp@alien8.de> - Andy Lutomirski <luto@kernel.org> - Josh Poimboeuf <jpoimboe@redhat.com> - Thomas Gleixner <tglx@linutronix.de> - Ingo Molnar <mingo@redhat.com> - linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> - Linux API <linux-api@vger.kernel.org> - Oleg Nesterov <oleg@redhat.com> - Daniel Micay <danielmicay@gmail.com> - James Morse <james.morse@arm.com> - Eric W . Biederman <ebiederm@xmission.com> - Martin Schwidefsky <schwidefsky@de.ibm.com> - Paolo Bonzini <pbonzini@redhat.com> - Andrew Morton <akpm@linux-foundation.org> - Thomas Garnier <thgarnie@google.com> - " Kirill A . Shutemov <kirill.shutemov@linux.intel.com>\0" + " Catalin Marinas <catalin.marinas@arm.com>\0" "\00:1\0" "b\0" "On Fri, 2017-05-12 at 22:41 +0100, Al Viro wrote:\n" @@ -82,4 +62,4 @@ "stack, which means a stack overflow will not overwrite\n" the thread_info. -435b21b9f28a1dd4c43bb5556a3984bdc5e22ac044b71c0fc4612f8efc50c2eb +2c0c79151a2725d7dea633b311ac8f1d604f0afefc25249ad3cd89af72688f24
diff --git a/a/1.txt b/N2/1.txt index f596f6a..9852e84 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -4,21 +4,21 @@ On Fri, 2017-05-12 at 22:41 +0100, Al Viro 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: +> Really???Let's take a look at arm, for example: > > struct thread_info { -> unsigned long flags; /* low level flags */ -> int preempt_count; /* 0 => preemptable, +> ????????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 +> ????????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 +> Seriously, look at these beasts.??Overwriting ->addr_limit is nowhere > near -> the top threat. If attacker can overwrite thread_info, you have +> the top threat.??If attacker can overwrite thread_info, you have > lost. That is why THREAD_INFO_IN_TASK exists. It moves diff --git a/a/content_digest b/N2/content_digest index b0bb741..9e03bfe 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -9,49 +9,10 @@ "ref\020170512210645.GS390@ZenIV.linux.org.uk\0" "ref\0CAGXu5jJu=VTqp2tzkPB4RAVxdGC+_SSQwrUwdzWpu24AA-zEcg@mail.gmail.com\0" "ref\020170512214144.GT390@ZenIV.linux.org.uk\0" - "From\0Rik van Riel <riel@redhat.com>\0" - "Subject\0Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode\0" + "From\0riel@redhat.com (Rik van Riel)\0" + "Subject\0[kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode\0" "Date\0Fri, 12 May 2017 17:47:55 -0400\0" - "To\0Al Viro <viro@zeniv.linux.org.uk>" - " Kees Cook <keescook@chromium.org>\0" - "Cc\0Russell King - ARM Linux <linux@armlinux.org.uk>" - Linus Torvalds <torvalds@linux-foundation.org> - Mark Rutland <mark.rutland@arm.com> - Kernel Hardening <kernel-hardening@lists.openwall.com> - Greg KH <greg@kroah.com> - Heiko Carstens <heiko.carstens@de.ibm.com> - LKML <linux-kernel@vger.kernel.org> - David Howells <dhowells@redhat.com> - Dave Hansen <dave.hansen@intel.com> - H . Peter Anvin <hpa@zytor.com> - Ingo Molnar <mingo@kernel.org> - Pavel Tikhomirov <ptikhomirov@virtuozzo.com> - linux-s390 <linux-s390@vger.kernel.org> - the arch/x86 maintainers <x86@kernel.org> - Will Deacon <will.deacon@arm.com> - Christian Borntraeger <borntraeger@de.ibm.com> - " Ren\303\251 Nyffenegger <mail@renenyffenegger.ch>" - Catalin Marinas <catalin.marinas@arm.com> - Paul E . McKenney <paulmck@linux.vnet.ibm.com> - Peter Zijlstra <a.p.zijlstra@chello.nl> - Arnd Bergmann <arnd@arndb.de> - Brian Gerst <brgerst@gmail.com> - Borislav Petkov <bp@alien8.de> - Andy Lutomirski <luto@kernel.org> - Josh Poimboeuf <jpoimboe@redhat.com> - Thomas Gleixner <tglx@linutronix.de> - Ingo Molnar <mingo@redhat.com> - linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> - Linux API <linux-api@vger.kernel.org> - Oleg Nesterov <oleg@redhat.com> - Daniel Micay <danielmicay@gmail.com> - James Morse <james.morse@arm.com> - Eric W . Biederman <ebiederm@xmission.com> - Martin Schwidefsky <schwidefsky@de.ibm.com> - Paolo Bonzini <pbonzini@redhat.com> - Andrew Morton <akpm@linux-foundation.org> - Thomas Garnier <thgarnie@google.com> - " Kirill A . Shutemov <kirill.shutemov@linux.intel.com>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Fri, 2017-05-12 at 22:41 +0100, Al Viro wrote:\n" @@ -60,21 +21,21 @@ "> > Two things are at risk from stack exhaustion: thread_info (mainly\n" "> > addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and\n" "> \n" - "> Really?\302\240\302\240Let's take a look at arm, for example:\n" + "> Really???Let's take a look at arm, for example:\n" "> \n" "> struct thread_info {\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240unsigned long\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240flags;\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240/* low level flags */\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240int\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240preempt_count;\302\240\302\240/* 0 => preemptable,\n" + "> ????????unsigned long???????????flags;??????????/* low level flags */\n" + "> ????????int?????????????????????preempt_count;??/* 0 => preemptable,\n" "> <0 => bug */\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240mm_segment_t\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240addr_limit;\302\240\302\240\302\240\302\240\302\240/* address limit */\n" - "> \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240struct task_struct\302\240\302\240\302\240\302\240\302\240\302\240*task;\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240/* main task\n" + "> ????????mm_segment_t????????????addr_limit;?????/* address limit */\n" + "> ????????struct task_struct??????*task;??????????/* main task\n" "> structure */\n" "> \n" "> and current() is defined as current_thread_info()->task.\n" "> \n" - "> Seriously, look at these beasts.\302\240\302\240Overwriting ->addr_limit is nowhere\n" + "> Seriously, look at these beasts.??Overwriting ->addr_limit is nowhere\n" "> near\n" - "> the top threat.\302\240\302\240If attacker can overwrite thread_info, you have\n" + "> the top threat.??If attacker can overwrite thread_info, you have\n" "> lost.\n" "\n" "That is why THREAD_INFO_IN_TASK exists. It moves\n" @@ -82,4 +43,4 @@ "stack, which means a stack overflow will not overwrite\n" the thread_info. -435b21b9f28a1dd4c43bb5556a3984bdc5e22ac044b71c0fc4612f8efc50c2eb +51b99e4d73a5536ffcf5bfba6240982ed9d05460fc4108a97c7e3a8278606206
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.