Bug 190083

Summary: [PATCH] i386/x86-64: Fix x87 information leak between processes (CVE-2006-1056)
Product: [Retired] Fedora Legacy Reporter: James Kosin <jkosin>
Component: kernelAssignee: Fedora Legacy Bugs <bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecified   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=d296e6191afbfc63077da02a1386bcd73bd4c1e0
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-24 22:23:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Patch for CVE-2006-1056 none

Description James Kosin 2006-04-27 12:59:08 UTC
[PATCH] i386/x86-64: Fix x87 information leak between processes

AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
when an exception is pending. This means the value leak through
context switches and allow processes to observe some x87 instruction
state of other processes.

This was actually documented by AMD, but nobody recognized it as
being different from Intel before.

The fix first adds an optimization: instead of unconditionally
calling FNCLEX after each FXSAVE test if ES is pending and skip
it when not needed. Then do a dummy x87 load to clear FOP/FIP/FDP.
This means other processes always will only see a constant value
defined by the kernel.

Then it does a ffree st(7) ; fild
This is executed unconditionally on FXSAVE capable systems, but has
been benchmarked on Intel systems to be reasonably fast.

I also had to move unlazy_fpu for 64bit to make sure the code
always executes with the data segment of the new process to prevent
leaking the old one.

Patch for both i386/x86-64.

The problem was discovered originally by Jan Beulich. Richard
Brunner provided the basic code for the workarounds with contributions
from Jan.

This is CVE-2006-1056

Signed-off-by: Andi Kleen


Comment 1 James Kosin 2006-04-27 12:59:08 UTC
Created attachment 128306 [details]
Patch for CVE-2006-1056

Comment 2 Marc Deslauriers 2006-07-24 22:23:18 UTC

*** This bug has been marked as a duplicate of 200034 ***