From owner-freebsd-security@FreeBSD.ORG Tue Jun 19 18:47:41 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92E19106566B; Tue, 19 Jun 2012 18:47:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 640178FC0C; Tue, 19 Jun 2012 18:47:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C86E1B962; Tue, 19 Jun 2012 14:47:40 -0400 (EDT) From: John Baldwin To: freebsd-security@freebsd.org Date: Tue, 19 Jun 2012 14:44:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <497105EC-3223-4E59-A6E6-F810A15BCA5C@FreeBSD.org> <4FE0C1DA.2080809@pyro.eu.org> In-Reply-To: <4FE0C1DA.2080809@pyro.eu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206191444.35285.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 19 Jun 2012 14:47:40 -0400 (EDT) Cc: bz@freebsd.org, "Simon L. B. Nielsen" , Steven Chamberlain Subject: Re: Update for FreeBSD Security Advisory FreeBSD-SA-12:04.sysret for 8.1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 18:47:41 -0000 On Tuesday, June 19, 2012 2:15:54 pm Steven Chamberlain wrote: > Hi, > > Thanks a lot of looking into this! > > On 18/06/12 22:37, Simon L. B. Nielsen wrote: > > Note that this is ONLY for FreeBSD 8.1. Other branches are OK. > > Having seen the correct fix now, I'm starting to wonder if the commit to > RELENG_7_4 was really okay too? > > http://svnweb.freebsd.org/base/releng/7.4/sys/amd64/amd64/trap.c?annotate=236953#l975 > > The inserted code does not appear at the end of the function, like it > does now in all other versions including 8.1 which is the most similar. > > I expect this would at least trap if the exploit was attempted, but then > it would omit the rest of the function, including userret(); would that > have consequences? It would perhaps be best to occur at the end of the function to be consistent. However, the fix is functionally correct in this case. -- John Baldwin