[CVE-2014-9090] x86_64, traps: Stop using IST for #SS

Willy Tarreau w at 1wt.eu
Fri Dec 5 17:05:46 UTC 2014


Hi Luis,

On Fri, Dec 05, 2014 at 03:21:01PM +0000, Luis Henriques wrote:
> Now, are they all really required for fixing CVE-2014-9090?  Or are
> they just some other miscellaneous fixes?  Some of them are *really*
> frightening :-)

Most of them were missing previously, and running Andy's test code
showed that something was really odd. I started to look at what was
missing in this area and noticed that in lately I missed a few fixes
that I thought were irrelevant given that they didn't apply, but that
they were needed. A few of them are just here because I carefully
diffed 2.6.32 and 3.10 and found some strange missing one-liners
that were fixed a long time ago and never backported. Another one
(K8-Bstep) was just to fix the diff context since during the first
attempt at fixing the bad_iret code I messed up my backport because
of this one being missing which fooled me into fixing the wrong jump.

> Your backport of commit 6f442be2fb22 ("x86_64, traps: Stop using IST
> for #SS") seems to be identical to mine, but I'm unable to confirm
> that it is sufficient to fix the security issue.

It should be. I can't tell the CVEs for the other ones if any, I've
always been inefficient at digging through CVEs. But if you want to
get the bad_iret code fixed and to disable X86_16BIT (which is
strongly recommended on servers), your certainly need almost all
the list if you don't want to play with fire by fixing sensible
backports by hand...

> > I'm attaching the whole list as a tgz. Maybe the last two will not yet
> > get in, I'm synchronizing with Greg on this.
> > 
> 
> Yeah, I remember Andy asking on the stable mailing-list to hold these
> two patches for a week or two, so I dropped both from the 3.16 kernel
> queue and added them to my TODO :)

Greg and I tend to think we'll merge them anyway. The code around this
part is 1) ugly and 2) very tricky. Nobody feels confident enough in
the fact that it's not possible to exploit them further it seems...

Anyway I won't merge a patch not in Greg's trees so I'll align to his
choice.

Cheers,
Willy





More information about the kernel-team mailing list