linux-kernel - [patch] x64, fpu: fix possible FPU leakage in error conditions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080724180429.GI14380@linux-os.sc.intel.com>
Date:	Thu, 24 Jul 2008 11:04:29 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	x86@...nel.org, andi@...stfloor.org, torvalds@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: [patch] x64, fpu: fix possible FPU leakage in error conditions

restore_fpu_checking() calls init_fpu() in error conditions. init_fpu()
just touches the FPU state in the thread struct and doesn't do anything
with the live FPU registers. While this is wrong(as our main intention is
to init the live FPU registers aswell), this was benign
before the commit 92d140e21f1ce8cf99320afbbcad73879128e6dc.

Post commit 92d140e21f1ce8cf99320afbbcad73879128e6dc, live FPU registers
may not belong to this process at this error scenario.

In the error condition for restore_fpu_checking() (especially during
the 64bit signal return), we are doing init_fpu(), which saves the live
FPU register state (possibly belonging to some other process context) into the
thread struct (through unlazy_fpu() in init_fpu()). This is wrong and can leak
the FPU data.

Remove the unlazy_fpu() from the init_fpu(). init_fpu() will now always
init the FPU data in the thread struct. For the error conditions in
restore_fpu_checking(), restore the initialized FPU data from the thread
struct.

Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
---

diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index eb9ddd8..f5c2161 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -98,12 +98,6 @@ void __cpuinit fpu_init(void)
  */
 int init_fpu(struct task_struct *tsk)
 {
-	if (tsk_used_math(tsk)) {
-		if (HAVE_HWFP && tsk == current)
-			unlazy_fpu(tsk);
-		return 0;
-	}
-
 	/*
 	 * Memory allocation at the first usage of the FPU and other state.
 	 */
diff --git a/include/asm-x86/i387.h b/include/asm-x86/i387.h
index 37672f7..38af0ed 100644
--- a/include/asm-x86/i387.h
+++ b/include/asm-x86/i387.h
@@ -45,6 +45,12 @@ static inline void tolerant_fwait(void)
 		     _ASM_EXTABLE(1b, 2b));
 }

+static inline void restore_fpu(struct i387_fxsave_struct *fx)
+{
+	__asm__ __volatile__("rex64/fxrstor (%[fx])"
+			     :: [fx] "cdaSDb" (fx), "m" (*fx));
+}
+
 static inline int restore_fpu_checking(struct i387_fxsave_struct *fx)
 {
 	int err;
@@ -62,8 +68,10 @@ static inline int restore_fpu_checking(struct i387_fxsave_struct *fx)
 #else
 		     : [fx] "cdaSDb" (fx), "m" (*fx), "0" (0));
 #endif
-	if (unlikely(err))
+	if (unlikely(err)) {
 		init_fpu(current);
+		restore_fpu(&current->thread.xstate->fxsave);
+	}
 	return err;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/