linux-kernel - [PATCH 0/1] x86, fpu: shift drop_init_fpu() from save_xstate_sig() to handle

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]

Date:	Fri, 22 Aug 2014 19:11:42 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Al Viro <viro@...IV.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Bean Anderson <bean@...lsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/1] x86, fpu: shift drop_init_fpu() from save_xstate_sig()
	to handle_signal()

Al, Linus, could you take a look?

Looks simple, but I have to admit that every time I read FPU code
I feel that I never read it before. And I never really understood
it in details.

See the changelog, but in short drop_init_fpu() in save_xstate_sig()
looks wrong. This assumes that we are going to call the handler and
thus we need the new FPU state. But this is only true if setup_frame()
won't fail after that. If it fails, we simply lose the FPU state.

Many thanks to Bean Anderson for the detailed report, let me quote it:

	(1) A real-time signal is being delivered to a thread.
	(2) There is not enough room to push the ucontext on the
	    stack so a SIGSEGV is generated
	(3) The segv handler is running on the sigaltstack.
	(4) The ucontext received by the segv handler does not contain
	    the FP registers. And on return from the segv handler, the
	    existing FP registers appear to be zero'd out.

Oleg.

--
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/