From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756927AbaFXUxu (ORCPT ); Tue, 24 Jun 2014 16:53:50 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:51554 "EHLO mail-la0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753985AbaFXUxq convert rfc822-to-8bit (ORCPT ); Tue, 24 Jun 2014 16:53:46 -0400 MIME-Version: 1.0 In-Reply-To: <20140624105108.GG4439@pd.tnic> References: <20140624105108.GG4439@pd.tnic> From: Andy Lutomirski Date: Tue, 24 Jun 2014 13:53:25 -0700 Message-ID: Subject: Re: [PATCH] x86_32,entry: Do syscall exit work on badsys (CVE-2014-4508) To: Borislav Petkov Cc: "H. Peter Anvin" , Richard Weinberger , X86 ML , Eric Paris , Linux Kernel , "security@kernel.org" , Steven Rostedt , =?UTF-8?Q?Toralf_F=C3=B6rster?= , stable , Roland McGrath Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 24, 2014 at 3:51 AM, Borislav Petkov wrote: > On Mon, Jun 23, 2014 at 02:22:15PM -0700, Andy Lutomirski wrote: >> 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. >> >> This fixes an OOPS in the audit code when fast-path auditing is >> enabled and sysenter gets a bad syscall nr (CVE-2014-4508). >> >> This has probably been broken since Linux 2.6.27: >> af0575bba0 i386 syscall audit fast-path >> >> Cc: stable@vger.kernel.org >> Cc: Roland McGrath >> Reported-by: Toralf Förster >> Signed-off-by: Andy Lutomirski >> --- >> >> I realize that the syscall audit fast path and badsys code, on 32-bit >> x86 no less, is possibly one of the least fun things in the kernel to >> review, but this is still a real security bug and should get fixed :( >> >> So I'm cc-ing a bunch of people and maybe someone will review it. > > Well, AFAICS, you're rerouting execution so that the audit stuff gets > properly "unwound" before returning to userspace. Which makes sense to > me. > > Would it really work in all possible cases and isn't it causing any > other problems? > > No friggin' idea - it would need extensive hammering to confirm it is ok > IMHO. > > HTH. It confirms my sense that no one knows how to test this stuff :-/ It's pretty clear that no one has ever extensively hammered it. I wonder how much could be effectively rewritten in C. I'm thinking of redoing most of the entry work in C, but that won't help here. --Andy