[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mts4zkac.ffs@nanos.tec.linutronix.de>
Date: Sat, 05 Jun 2021 12:18:51 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Dave Hansen <dave.hansen@...el.com>,
LKML <linux-kernel@...r.kernel.org>
Cc: x86@...nel.org, Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Tony Luck <tony.luck@...el.com>,
Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [patch 0/8] x86/fpu: Mop up XSAVES and related damage
On Fri, Jun 04 2021 at 15:04, Dave Hansen wrote:
> The nice Intel 0day folks threw some tests at this series. It managed
> to trigger an oops. I can't right this moment publish the source for
> the test, but it looks pretty trivial. It basically creates a 0'd XSAVE
> buffer, sets XCOMP_BV to:
>
> #define XSAVES_FEATURES ( \
> XFEATURE_MASK_PT | \
> XFEATURE_MASK_SHSTK_USER | \
> XFEATURE_MASK_SHSTK_KERNEL | \
> 0x8000000000000000 \
> )
>
> Then passes that buffer in to ptrace(PTRACE_SETREGSET, ...).
>
> The oops is below. It doesn't *look* to be XSAVES-related. The oops
> looks like it's happening in xstateregs_set() itself as opposed to down
> in the code actually concerned with supervisor state.
>
> No bug is jumping out of the code as I took a brief look at it. The
> xbuf versus kbuf code looks a bit wonky, but I can't find a hole in it.
I can....
--- a/arch/x86/kernel/fpu/regset.c
+++ b/arch/x86/kernel/fpu/regset.c
@@ -128,7 +128,7 @@ int xstateregs_set(struct task_struct *t
xbuf = vmalloc(count);
if (!xbuf)
return -ENOMEM;
- ret = user_regset_copyin(&pos, &count, NULL, &ubuf, xbuf, 0, -1);
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, xbuf, 0, -1);
if (ret)
goto out;
}
Powered by blists - more mailing lists