Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753594AbaFWVEc (ORCPT ); Mon, 23 Jun 2014 17:04:32 -0400 Received: from mail-oa0-f45.google.com ([209.85.219.45]:61959 "EHLO mail-oa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752628AbaFWVEb (ORCPT ); Mon, 23 Jun 2014 17:04:31 -0400 MIME-Version: 1.0 In-Reply-To: References: <539F1C59.6070308@gmx.de> <539F297F.7010904@nod.at> <539F2B2D.6050105@gmx.de> <539F3077.7040005@gmx.de> <539F35A0.2050002@gmx.de> <539F567F.2050802@gmx.de> <539F5702.5050104@nod.at> <539F6646.4040605@zytor.com> Date: Mon, 23 Jun 2014 17:04:30 -0400 X-Google-Sender-Auth: PRnup_iMfhF_8fJOVvtZi-Y68rM Message-ID: Subject: Re: 3.15: kernel BUG at kernel/auditsc.c:1525! From: Josh Boyer To: Andy Lutomirski Cc: "H. Peter Anvin" , Richard Weinberger , X86 ML , =?ISO-8859-1?Q?Toralf_F=F6rster?= , Eric Paris , Linux Kernel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 20, 2014 at 11:41 AM, Andy Lutomirski wrote: > On Mon, Jun 16, 2014 at 2:48 PM, H. Peter Anvin wrote: >> On 06/16/2014 02:35 PM, Andy Lutomirski wrote: >>> >>> To hpa, etc: It appears that entry_32.S is missing any call to the >>> audit exit hook on the badsys path. If I'm diagnosing this bug report >>> correctly, this causes OOPSes. >>> >>> The the world at large: it's increasingly apparent that no one (except >>> maybe the blackhats) has ever scrutinized the syscall auditing code. >>> This is two old severe bugs in the code that have probably been there >>> for a long time. >>> >> >> Yes, the audit code is a total mess. >> >>> The bad syscall nr paths are their own incomprehensible route >>> through the entry control flow. Rearrange them to work just like >>> syscalls that return -ENOSYS. >> >> I have to admit... it sort of lends itself to a solution like this: >> >> /* For the 64-bit case, analogous code for 32 bits */ >> movl $__NR_syscall_max+1,%ecx # *Not* __NR_syscall_max >> cmpq %rcx,%rax >> cmovae %rcx,%rax >> movq %r10,%rcx >> call *sys_call_table(,%rax,8) >> >> ... and having an extra (invalid) system call slot in the syscall table >> beyond the end instead of branching off separately. >> >> (Note: we could use either cmova or cmovae, and either the 32- or 64-bit >> form... the reason why is left as an exercise to the reader.) > > This is CVE-2014-4508, and it's probably worth fixing. > > Is my patch good? I can resent and cc stable if needed. I'm planning on picking this up for Fedora tomorrow unless someone screams it's the wrong fix. Honestly though, it would be nice to get an indication either way. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/