linux-kernel - Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Feb 2009 17:32:13 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Norbert Preining <preining@...ic.at>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>
Subject: Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12505
> > Subject		: 2.6.29-rc1 Firefox crashing on page load
> > Submitter	: Justin Madru <jdm64@...ab.com>
> > Date		: 2009-01-16 20:56 (20 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
> > References	: http://marc.info/?l=linux-kernel&m=123213941914274&w=4
> > Handled-By	: Justin P. Mattock <justinmattock@...il.com>
> 
> Heh. That commit you point to is very innocuous.
> 
> Commit 4217458dafaa57d8e26a46f5d05ab8c53cf64191 is a pure cleanup, and it 
> _does_ make the code look nicer, but while it looks lik a total no-op, it 
> actually has a very subtle behavioural change: it makes gcc think that it 
> owns the whole argument stack. Which is _not_ true of 'asmlinkage' 
> functions, but we've never been able to tell gcc to keep its grubby hands 
> off our stack.
> 
> So I suspect that gcc inlines the function and then creates a function 
> call that re-uses the "struct pt_regs" on the stack as the argument area 
> too. Which corrupts the "pt_regs", and then we return to user space with 
> some random register contents.

yes - i tracked it down back then, just the regression entry didnt get 
updated.

> So I think we need to just revert it. Ingo, Hiroshi?

should be fixed upstream by:

 552b8aa: Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"

the revert commit is below with explaination - also with a Tested-by tag. 
The revert is not a pure revert - it also adds a comment to preserve this 
circumstance cleanly.

We first had a few fruitless attempts to annotate it in some clear fashion 
(the existing tailcall-avoidance macros we have didnt suit this case) - then 
went for the revert because none of the variants that told gcc not to screw 
up actually made the code better than it was originally.

	Ingo

-------------->
>From 552b8aa4d1edcc1c764ff6f61a7686347a2d1827 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...e.hu>
Date: Tue, 20 Jan 2009 09:31:49 +0100
Subject: [PATCH] Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"

This reverts commit 4217458dafaa57d8e26a46f5d05ab8c53cf64191.

Justin Madru bisected this commit, it was causing weird Firefox
crashes.

The reason is that GCC mis-optimizes (re-uses) the on-stack parameters of
the calling frame, which corrupts the syscall return pt_regs state and
thus corrupts user-space register state.

So we go back to the slightly less clean but more optimization-safe
method of getting to pt_regs. Also add a comment to explain this.

Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=12505

Reported-and-bisected-by: Justin Madru <jdm64@...ab.com>
Tested-by: Justin Madru <jdm64@...ab.com>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 arch/x86/include/asm/syscalls.h |    2 +-
 arch/x86/kernel/signal.c        |   11 +++++++++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 9c6797c..c0b0bda 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -40,7 +40,7 @@ asmlinkage int sys_sigaction(int, const struct old_sigaction __user *,
 			     struct old_sigaction __user *);
 asmlinkage int sys_sigaltstack(unsigned long);
 asmlinkage unsigned long sys_sigreturn(unsigned long);
-asmlinkage int sys_rt_sigreturn(struct pt_regs);
+asmlinkage int sys_rt_sigreturn(unsigned long);
 
 /* kernel/ioport.c */
 asmlinkage long sys_iopl(unsigned long);
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 89bb766..df0587f 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -632,9 +632,16 @@ badframe:
 }
 
 #ifdef CONFIG_X86_32
-asmlinkage int sys_rt_sigreturn(struct pt_regs regs)
+/*
+ * Note: do not pass in pt_regs directly as with tail-call optimization
+ * GCC will incorrectly stomp on the caller's frame and corrupt user-space
+ * register state:
+ */
+asmlinkage int sys_rt_sigreturn(unsigned long __unused)
 {
-	return do_rt_sigreturn(&regs);
+	struct pt_regs *regs = (struct pt_regs *)&__unused;
+
+	return do_rt_sigreturn(regs);
 }
 #else /* !CONFIG_X86_32 */
 asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
--
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/