All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Richard Weinberger" <richard@nod.at>, "X86 ML" <x86@kernel.org>,
	"Toralf Förster" <toralf.foerster@gmx.de>,
	"Eric Paris" <eparis@redhat.com>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: 3.15: kernel BUG at kernel/auditsc.c:1525!
Date: Mon, 16 Jun 2014 14:54:40 -0700	[thread overview]
Message-ID: <CALCETrUWpXWLn4wfV6wneOwX+12fbFZ2af=JrZiwq-5RGYiT4Q@mail.gmail.com> (raw)
In-Reply-To: <539F6646.4040605@zytor.com>

On Mon, Jun 16, 2014 at 2:48 PM, H. Peter Anvin <hpa@zytor.com> 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.)

For 64-bit, I want to do this instead:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/seccomp-fastpath&id=a5ec2d7af2c54b55fc7201fa662138b53fbbda39

I see no reason why the 64-bit badsys code needs its own code path at
all.  I haven't sent it yet because AFAICT it doesn't fix any bug, and
the series it's a part of isn't ready.

I'm also contemplating rewriting the 64-bit syscall entry work path in C.


--Andy

  reply	other threads:[~2014-06-16 21:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-16 16:33 3.15: kernel BUG at kernel/auditsc.c:1525! Toralf Förster
2014-06-16 17:21 ` Richard Weinberger
2014-06-16 17:25   ` Andy Lutomirski
2014-06-16 17:29     ` Richard Weinberger
2014-06-16 17:32       ` Andy Lutomirski
2014-06-16 17:36         ` Toralf Förster
2014-06-16 17:50           ` Andy Lutomirski
2014-06-16 17:59             ` Toralf Förster
2014-06-16 18:15               ` Andy Lutomirski
2014-06-16 18:21                 ` Toralf Förster
2014-06-16 18:24                   ` Andy Lutomirski
2014-06-16 18:36                     ` Toralf Förster
2014-06-16 20:41                     ` Toralf Förster
2014-06-16 20:43                       ` Richard Weinberger
2014-06-16 21:35                         ` Andy Lutomirski
2014-06-16 21:48                           ` H. Peter Anvin
2014-06-16 21:54                             ` Andy Lutomirski [this message]
2014-06-16 21:58                               ` H. Peter Anvin
2014-06-16 22:00                                 ` Andy Lutomirski
2014-06-20 15:41                             ` Andy Lutomirski
2014-06-20 17:35                               ` Toralf Förster
2014-06-23 21:04                               ` Josh Boyer
2014-06-23 21:22                                 ` [PATCH] x86_32,entry: Do syscall exit work on badsys (CVE-2014-4508) Andy Lutomirski
2014-06-23 22:18                                   ` [tip:x86/urgent] x86_32, entry: Do syscall exit work on badsys ( CVE-2014-4508) tip-bot for Andy Lutomirski
2014-06-24 10:51                                   ` [PATCH] x86_32,entry: Do syscall exit work on badsys (CVE-2014-4508) Borislav Petkov
2014-06-24 20:53                                     ` Andy Lutomirski
2014-06-24 21:18                                       ` Borislav Petkov
2014-07-01 10:52                                   ` Quentin Casasnovas
2014-07-01 14:14                                     ` Andy Lutomirski
2014-06-17 15:38                           ` 3.15: kernel BUG at kernel/auditsc.c:1525! Toralf Förster
2014-06-17 16:19                             ` Andy Lutomirski
2014-06-20  4:44                           ` Fwd: " Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrUWpXWLn4wfV6wneOwX+12fbFZ2af=JrZiwq-5RGYiT4Q@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=eparis@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=toralf.foerster@gmx.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.