From: "Yu, Yu-cheng" <yu-cheng.yu@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@kernel.org>,
syzbot <syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com>,
bp@alien8.de, bp@suse.de, dave.hansen@linux.intel.com,
fenghua.yu@intel.com, hpa@zytor.com,
linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, syzkaller-bugs@googlegroups.com,
tony.luck@intel.com, x86@kernel.org
Subject: Re: [syzbot] WARNING in ex_handler_fprestore
Date: Thu, 27 May 2021 11:59:34 -0700 [thread overview]
Message-ID: <b2dddfbc-02cd-fcd8-6c89-ae6204e4cf6f@intel.com> (raw)
In-Reply-To: <87bl8w86m3.ffs@nanos.tec.linutronix.de>
On 5/27/2021 9:49 AM, Thomas Gleixner wrote:
> On Thu, May 27 2021 at 00:03, Thomas Gleixner wrote:
>> I decoded it fully by now and will send out coherent info (and hopefully
>> a patch) tomorrow with brain awake. Time for bed here...
>
> Not yet there with a patch, but I have a trivial C reproducer. See
> below.
>
> The failure mode is:
>
> signal to task
> sigaction_handler()
> wreckage xsave.header.reserved[0]
> sig_return()
> restore_fpu_from_sigframe()
> try: XRSTOR from user -> #GP
> copy_from_user(fpstate, task->fpu.state.xsave);
> validate(task->fpu.state.xsave) -> fail
> fpu__clear_user_states()
> reinits FPU hardware but task state is still wreckaged
In fpu__clear_user_states(), maybe can we clear xstate_header.reserved[]
as well? Or do we want to check the user buffer first before copy it?
> signal_fault()
> sigsegv_handler()
> sig_return()
> restore_fpu_from_sigframe()
> try: XRSTOR from user -> success
>
> schedule()
> xsave()
>
> other task runs on same CPU so fpu state is not longer clean
>
> wakeup()
> exit_to_user()
> xrstor() -> #GP because the header is still borked.
>
> XSAVE does not clear the header.reserved fields....
>
> The original code kinda worked because fpu__clear() reinitialized the
> task fpu state, but as this code is preemptible the same issue can
> happen pre 5.8 as well if I'm not missing something. I'll verify that
> after dinner.
>
> The commit in question just made it trivial to trigger because it keeps
> the broken task fpu state around.
>
> The whole slow path is broken in disgusting ways. I have no good idea
> yet how to fix that proper and in a way which can be backported easily.
>
> Thanks,
>
> tglx
> ---
> #define _GNU_SOURCE
>
> #include <errno.h>
> #include <pthread.h>
> #include <signal.h>
> #include <stdlib.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> #include <unistd.h>
> #include <sched.h>
>
> static void sig_handler(int sig, siginfo_t *info, void *__ctxp)
> {
> ucontext_t *uctx = __ctxp;
> mcontext_t *mctx = &uctx->uc_mcontext;
> unsigned long *p = (unsigned long *) mctx->fpregs;
>
> /* Wreckage xsave.header.reserved[0] */
> p[66] = 0xfffffff;
> }
>
> static void sigsegv(int sig)
> {
> }
>
> int main(void)
> {
> struct sigaction sa;
> cpu_set_t set;
>
> memset(&sa, 0, sizeof(sa));
> sa.sa_sigaction = sig_handler;
> sa.sa_flags = SA_SIGINFO;
> sigemptyset(&sa.sa_mask);
> if (sigaction(SIGUSR1, &sa, 0))
> exit(1);
>
> signal(SIGSEGV, sigsegv);
>
> CPU_ZERO(&set);
> CPU_SET(0, &set);
>
> sched_setaffinity(getpid(), sizeof(set), &set);
>
> kill(0, SIGUSR1);
> fork();
> sleep(1);
>
> return 0;
> }
>
next prev parent reply other threads:[~2021-05-27 18:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 8:51 syzbot
2021-05-26 0:33 ` Andy Lutomirski
2021-05-26 7:00 ` Dmitry Vyukov
2021-05-26 21:21 ` Yu, Yu-cheng
2021-05-26 22:37 ` Andy Lutomirski
2021-05-26 22:03 ` Thomas Gleixner
2021-05-27 16:49 ` Thomas Gleixner
2021-05-27 18:59 ` Yu, Yu-cheng [this message]
2021-05-27 19:17 ` Thomas Gleixner
2021-05-27 19:05 ` Thomas Gleixner
2021-05-31 17:46 ` syzbot
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=b2dddfbc-02cd-fcd8-6c89-ae6204e4cf6f@intel.com \
--to=yu-cheng.yu@intel.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®