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:
> 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.
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
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'.
Tim Gardner email@example.com
kernel-team mailing list