linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: 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, yu-cheng.yu@intel.com
Subject: Re: [syzbot] WARNING in ex_handler_fprestore
Date: Thu, 27 May 2021 18:49:08 +0200	[thread overview]
Message-ID: <87bl8w86m3.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <87sg29886g.ffs@nanos.tec.linutronix.de>

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
          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;
}

  reply	other threads:[~2021-05-27 16:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24  8:51 [syzbot] WARNING in ex_handler_fprestore 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 [this message]
2021-05-27 18:59       ` Yu, Yu-cheng
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=87bl8w86m3.ffs@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --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=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).