pending stable kernel security updates

[Tim Gardner]

Kees Cook wrote:
> On Tue, Jun 24, 2008 at 08:45:38AM -0600, Tim Gardner wrote:
>> Kees Cook wrote:
>>> I need help with CVE-2008-1615: the code has changed a lot between
>>> revisions, has been touched by the virt bits, and is pretty non-obvious
>>> to me.
>> Kees - As far as I can tell CVE-2008-1615 does not apply to
>> Dapper/Feisty/Gutsy/Hardy. See
> 
> That's what I was thinking too, except that I got seriously confused
> comparing the upstream fix (a57dae3aa4d00a000b5bac4238025438204c78b2)
> with what was in the RH bug and what Debian used:
> 
> https://bugzilla.redhat.com/attachment.cgi?id=294062
> http://svn.debian.org/wsvn/kernel/dists/etch-security/linux-2.6/debian/patches/bugfix/amd64-cs-corruption.patch?op=file&rev=0&sc=0
> 
> It seems almost unrelated to the upstream commit.  ?
> 
>> You can also read Roland McGrath's somewhat caustic commit log entry in
>> a57dae3aa4d00a000b5bac4238025438204c78b2 if you are in need of some humor.
> 
> Yeah, owchy.  :)
> 
> -Kees
> 

It looks like there are 2 ways CS can get corrupted (and two fixes for
these corruption cases), e.g., the original patch against 2.6.4 and
higher (the Debian patch), and the Roland McGrath patch (which is a bit
of a red herring in the bugzilla report, nor does it really apply to
this CVE).

The Debian patch looks correct. Its my guess that 'RESTORE_ALL 8'
immediately prior to 'iretq' does not restore segment registers. Due to
assembler magic the jump to the iret_label symbol will load CS with the
destination segment, in essence restoring CS to the trap segment which
is necessary for a successful 'iretq'.

rtg
-- 
Tim Gardner tim.gardner at ubuntu.com