From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Lutomirski <luto@kernel.org>, x86@kernel.org
Cc: Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@kernel.org>,
stable@vger.kernel.org,
syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com
Subject: Re: [RFC v2 1/2] x86/fpu: Fix state corruption in __fpu__restore_sig()
Date: Mon, 31 May 2021 21:48:17 +0200 [thread overview]
Message-ID: <87czt64rcu.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <87fsy24tqt.ffs@nanos.tec.linutronix.de>
On Mon, May 31 2021 at 20:56, Thomas Gleixner wrote:
> On Mon, May 31 2021 at 12:01, Thomas Gleixner wrote:
> __fpu__restore_sig()
>
> if (!buf) {
> fpu__clear_user_states(fpu);
> return 0;
> }
>
> and
>
> handle_signal()
>
> if (!failed)
> fpu__clear_user_states(fpu);
>
> which invoke that function unconditionally.
So we cannot warn there.
This is all wrong and everything should use copy_kernel_to_xstate()
after copying the buffer from user space. But of course allocating
memory there is daft.
There is also xstateregs_set() which invokes fpstate_init() on fail
which means it blows away _ALL_ state including supervisor state.
Even without supervisor state this function is bonkers. If the ptracer
provides a bogus data set then this just invalidates the target tasks
FPU state for no real good reason.
This should just use a kernel buffer. If the copy from user fails, the
caller gets the EFAULT. If the header is bogus, then
copy_kernel_to_xstate() returns -EINVAL and that's handed back to the
caller. No reason to invalidate anything.
Thanks,
tglx
prev parent reply other threads:[~2021-05-31 19:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1622351443.git.luto@kernel.org>
2021-05-30 5:12 ` [RFC v2 1/2] x86/fpu: Fix state corruption in __fpu__restore_sig() Andy Lutomirski
2021-05-30 22:02 ` Thomas Gleixner
2021-05-30 23:41 ` Andy Lutomirski
2021-05-31 9:03 ` Thomas Gleixner
2021-05-31 10:01 ` Thomas Gleixner
2021-05-31 18:56 ` Thomas Gleixner
2021-05-31 19:30 ` Andy Lutomirski
2021-05-31 22:46 ` Thomas Gleixner
2021-06-01 4:58 ` Andy Lutomirski
2021-06-01 14:48 ` Dave Hansen
2021-06-01 18:06 ` [PATCH v3 3/5] x86/fpu: Clean up the fpu__clear() variants Dave Hansen
2021-06-01 18:14 ` Andy Lutomirski
2021-06-01 18:35 ` Dave Hansen
2021-06-01 22:44 ` Andy Lutomirski
2021-06-01 18:25 ` Thomas Gleixner
2021-06-01 23:17 ` [RFC v2 1/2] x86/fpu: Fix state corruption in __fpu__restore_sig() Thomas Gleixner
2021-05-31 19:48 ` Thomas Gleixner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czt64rcu.ffs@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=dave.hansen@intel.com \
--cc=luto@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.