Hello,
syzbot found the following issue on:
HEAD commit: 45af60e7 Merge tag 'for-5.13-rc2-tag' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1591e9f7d00000
kernel config: https://syzkaller.appspot.com/x/.config?x=18fade5827eb74f7
dashboard link: https://syzkaller.appspot.com/bug?extid=2067e764dbcd10721e2e
compiler: Debian clang version 11.0.1-2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11be6bd1d00000
The issue was bisected to:
commit b860eb8dce5906b14e3a7f3c771e0b3d6ef61b94
Author: Fenghua Yu <[email protected]>
Date: Tue May 12 14:54:39 2020 +0000
x86/fpu/xstate: Define new functions for clearing fpregs and xstates
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17c2c723d00000
final oops: https://syzkaller.appspot.com/x/report.txt?x=1422c723d00000
console output: https://syzkaller.appspot.com/x/log.txt?x=1022c723d00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
Fixes: b860eb8dce59 ("x86/fpu/xstate: Define new functions for clearing fpregs and xstates")
------------[ cut here ]------------
Bad FPU state detected at copy_kernel_to_xregs arch/x86/include/asm/fpu/internal.h:344 [inline], reinitializing FPU registers.
Bad FPU state detected at __copy_kernel_to_fpregs arch/x86/include/asm/fpu/internal.h:419 [inline], reinitializing FPU registers.
Bad FPU state detected at copy_kernel_to_fpregs arch/x86/include/asm/fpu/internal.h:443 [inline], reinitializing FPU registers.
Bad FPU state detected at __fpregs_load_activate+0x1a1/0x290 arch/x86/include/asm/fpu/internal.h:514, reinitializing FPU registers.
WARNING: CPU: 0 PID: 8847 at arch/x86/mm/extable.c:66 ex_handler_fprestore+0xaf/0xe0 arch/x86/mm/extable.c:65
Modules linked in:
CPU: 0 PID: 8847 Comm: syz-executor.0 Not tainted 5.13.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ex_handler_fprestore+0xaf/0xe0 arch/x86/mm/extable.c:65
Code: 0f ae 2f b0 01 5b 41 5c 41 5e 41 5f c3 e8 a9 82 46 00 c6 05 70 65 ec 0c 01 48 c7 c7 60 58 2b 8a 4c 89 fe 31 c0 e8 31 cc 12 00 <0f> 0b eb b1 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff 48 89
RSP: 0000:ffffc90002757be0 EFLAGS: 00010046
RAX: 73b00bd88b4ed600 RBX: ffffffff8c28fb34 RCX: ffff88802e86b880
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: ffffffff8c28fb30 R08: ffffffff816552b2 R09: ffffed1017343f24
R10: ffffed1017343f24 R11: 0000000000000000 R12: dffffc0000000000
R13: ffffc90002757d78 R14: ffffc90002757df8 R15: ffffffff812e3061
FS: 00007f4e04656700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd7a623b88 CR3: 00000000190f1000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
fixup_exception+0x92/0xd0 arch/x86/mm/extable.c:183
__exc_general_protection arch/x86/kernel/traps.c:567 [inline]
exc_general_protection+0x112/0x370 arch/x86/kernel/traps.c:531
asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:571
RIP: 0010:fpregs_activate arch/x86/include/asm/fpu/internal.h:498 [inline]
RIP: 0010:__fpregs_load_activate+0x1a1/0x290 arch/x86/include/asm/fpu/internal.h:515
Code: e8 14 c3 98 00 48 8b 5c 24 40 0f 1f 44 00 00 e8 25 d7 50 00 e8 20 d7 50 00 48 89 df b8 ff ff ff ff ba ff ff ff ff 48 0f ae 2f <65> 4c 89 2d e7 be d3 7e 4c 89 ef e8 6f 07 00 00 4c 89 e8 48 c1 e8
RSP: 0000:ffffc90002757e20 EFLAGS: 00010093
RAX: 00000000ffffffff RBX: ffff88802e86d080 RCX: ffff88802e86b880
RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffff88802e86d080
RBP: ffffc90002757ee0 R08: ffffffff812e2f67 R09: ffffed1005d0d711
R10: ffffed1005d0d711 R11: 0000000000000000 R12: ffffc90002757e60
R13: ffff88802e86d040 R14: 1ffff920004eafc8 R15: dffffc0000000000
arch_exit_to_user_mode_prepare arch/x86/include/asm/entry-common.h:58 [inline]
exit_to_user_mode_prepare+0x1a0/0x200 kernel/entry/common.c:210
__syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
syscall_exit_to_user_mode+0x26/0x70 kernel/entry/common.c:301
do_syscall_64+0x4b/0xb0 arch/x86/entry/common.c:57
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665d9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4e04656218 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: 0000000000000000 RBX: 000000000056bf88 RCX: 00000000004665d9
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000000056bf88
RBP: 000000000056bf80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf8c
R13: 00007ffdd6442f5f R14: 00007f4e04656300 R15: 0000000000022000
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
On 5/24/21 1:51 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 45af60e7 Merge tag 'for-5.13-rc2-tag' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1591e9f7d00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=18fade5827eb74f7
> dashboard link: https://syzkaller.appspot.com/bug?extid=2067e764dbcd10721e2e
> compiler: Debian clang version 11.0.1-2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11be6bd1d00000
Hi syz people and x86 people-
I entirely believe that this bug is real and that syzbot bisected it
correctly, but I'm puzzled by the reproducer. It says:
ptrace$setregs(0xd, r0, 0x0, &(0x7f0000000080))
I would really, really expect this to result from PTRACE_SETREGSET or
PTRACE_SETFPREGS, but this is PTRACE_SETREGS.
Am I missing something really obvious here?
On Wed, May 26, 2021 at 2:33 AM Andy Lutomirski <[email protected]> wrote:
>
> On 5/24/21 1:51 AM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 45af60e7 Merge tag 'for-5.13-rc2-tag' of git://git.kernel...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1591e9f7d00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=18fade5827eb74f7
> > dashboard link: https://syzkaller.appspot.com/bug?extid=2067e764dbcd10721e2e
> > compiler: Debian clang version 11.0.1-2
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11be6bd1d00000
>
> Hi syz people and x86 people-
>
> I entirely believe that this bug is real and that syzbot bisected it
> correctly, but I'm puzzled by the reproducer. It says:
>
> ptrace$setregs(0xd, r0, 0x0, &(0x7f0000000080))
>
> I would really, really expect this to result from PTRACE_SETREGSET or
> PTRACE_SETFPREGS, but this is PTRACE_SETREGS.
>
> Am I missing something really obvious here?
Hi Andy,
Sometimes syzkaller uses data format from one syscall variant, but
actually invokes another.
But here it does _not_ seem to be the case: 0xd is actually
PTRACE_SETREGS. And the other ptrace calls in the reproducer are
PTRACE_SEIZE and PTRACE_SINGLESTEP.
So I would assume somehow it happened with PTRACE_SETREGS.
Is there any indication from hardware as to what's wrong with fpregs?
On 5/26/2021 12:00 AM, Dmitry Vyukov wrote:
> On Wed, May 26, 2021 at 2:33 AM Andy Lutomirski <[email protected]> wrote:
>>
>> On 5/24/21 1:51 AM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit: 45af60e7 Merge tag 'for-5.13-rc2-tag' of git://git.kernel...
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1591e9f7d00000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=18fade5827eb74f7
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=2067e764dbcd10721e2e
>>> compiler: Debian clang version 11.0.1-2
>>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11be6bd1d00000
>>
>> Hi syz people and x86 people-
>>
>> I entirely believe that this bug is real and that syzbot bisected it
>> correctly, but I'm puzzled by the reproducer. It says:
>>
>> ptrace$setregs(0xd, r0, 0x0, &(0x7f0000000080))
>>
>> I would really, really expect this to result from PTRACE_SETREGSET or
>> PTRACE_SETFPREGS, but this is PTRACE_SETREGS.
>>
>> Am I missing something really obvious here?
>
> Hi Andy,
>
> Sometimes syzkaller uses data format from one syscall variant, but
> actually invokes another.
> But here it does _not_ seem to be the case: 0xd is actually
> PTRACE_SETREGS. And the other ptrace calls in the reproducer are
> PTRACE_SEIZE and PTRACE_SINGLESTEP.
> So I would assume somehow it happened with PTRACE_SETREGS.
> Is there any indication from hardware as to what's wrong with fpregs?
>
PTRACE_SETREGS can change segment registers. The PTRACE_SETREGS is
using some uninitialized memory area. One possibility would be that
XRSTORS has a memory operand outside of segment limits.
On Tue, May 25 2021 at 17:33, Andy Lutomirski wrote:
> On 5/24/21 1:51 AM, syzbot wrote:
> I entirely believe that this bug is real and that syzbot bisected it
> correctly, but I'm puzzled by the reproducer. It says:
The bug is real and the bisection is correct.
> ptrace$setregs(0xd, r0, 0x0, &(0x7f0000000080))
>
> I would really, really expect this to result from PTRACE_SETREGSET or
> PTRACE_SETFPREGS, but this is PTRACE_SETREGS.
>
> Am I missing something really obvious here?
That ptrace muck is a red herring and has nothing to do with it.
I decoded it fully by now and will send out coherent info (and hopefully
a patch) tomorrow with brain awake. Time for bed here...
Thanks,
tglx
On 5/26/21 2:21 PM, Yu, Yu-cheng wrote:
> On 5/26/2021 12:00 AM, Dmitry Vyukov wrote:
>> On Wed, May 26, 2021 at 2:33 AM Andy Lutomirski <[email protected]> wrote:
>>>
>>> On 5/24/21 1:51 AM, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following issue on:
>>>>
>>>> HEAD commit: 45af60e7 Merge tag 'for-5.13-rc2-tag' of
>>>> git://git.kernel...
>>>> git tree: upstream
>>>> console output:
>>>> https://syzkaller.appspot.com/x/log.txt?x=1591e9f7d00000
>>>> kernel config:
>>>> https://syzkaller.appspot.com/x/.config?x=18fade5827eb74f7
>>>> dashboard link:
>>>> https://syzkaller.appspot.com/bug?extid=2067e764dbcd10721e2e
>>>> compiler: Debian clang version 11.0.1-2
>>>> syz repro:
>>>> https://syzkaller.appspot.com/x/repro.syz?x=11be6bd1d00000
>>>
>>> Hi syz people and x86 people-
>>>
>>> I entirely believe that this bug is real and that syzbot bisected it
>>> correctly, but I'm puzzled by the reproducer. It says:
>>>
>>> ptrace$setregs(0xd, r0, 0x0, &(0x7f0000000080))
>>>
>>> I would really, really expect this to result from PTRACE_SETREGSET or
>>> PTRACE_SETFPREGS, but this is PTRACE_SETREGS.
>>>
>>> Am I missing something really obvious here?
>>
>> Hi Andy,
>>
>> Sometimes syzkaller uses data format from one syscall variant, but
>> actually invokes another.
>> But here it does _not_ seem to be the case: 0xd is actually
>> PTRACE_SETREGS. And the other ptrace calls in the reproducer are
>> PTRACE_SEIZE and PTRACE_SINGLESTEP.
>> So I would assume somehow it happened with PTRACE_SETREGS.
>> Is there any indication from hardware as to what's wrong with fpregs?
>>
>
> PTRACE_SETREGS can change segment registers. The PTRACE_SETREGS is
> using some uninitialized memory area. One possibility would be that
> XRSTORS has a memory operand outside of segment limits.
It's a regression caused by your fpu__clear_user() patch. tglx and I
are working on it.
The syzbot report is confusing but correct.
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;
}
On Thu, May 27 2021 at 18:49, Thomas Gleixner wrote:
> On Thu, May 27 2021 at 00:03, Thomas Gleixner wrote:
> 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.
Yes, I was missing something and pre 5.8 _IS_ safe because fpu__clear()
wipes task->fpu.state. Preemption does not matter because
TIF_NEED_FPU_LOAD is set _before_ the copy from user happens and in the
failure case it is guaranteed that fpu__clear() is invoked before a
XRSTOR can happen from that wreckaged buffer.
So it's clearly this particular commit, which is sooo innocent according
to the submitter and fpu__clear() just helps to clean up the mess. It
just fails to clean up the mess which that commit created inside
fpu__clear() in the first place.
Clearly nothing of this whole system/user state seperation was
thoroughly tested, which means ANY patch which is XSTATE related is
blocked until this mess is analyzed and cleaned up.
From now on ANY patch which extends or modifies XSTATE handling has to
be accompanied by proper test cases and analysis. Without that such
patches are not even going to be reviewed. This applies to all patches
in flight as well.
I don't mind bugs, but unprofessionally dismissing a conclusive bisect
and handwaving about ptrace modified segment registers on X86_64 is just
not acceptable.
Thanks,
tglx
On Thu, May 27 2021 at 11:59, Yu-cheng Yu wrote:
> 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?
Just because my reproducer wreckages xstate_header.reserved, you think
it's sufficient to maybe clear that field? May I recommend to study the
XSAVE documentation?
> Or do we want to check the user buffer first before copy it?
Before your patch the code was correct. So maybe study the SDM, the code
and the commit and carefully read this email plus the following ones
before you come up with more helpful suggestions.
<SNIP>
80 lines of useless quotes
</SNIP>
See: https://people.kernel.org/tglx/notes-about-netiquette
Thanks,
tglx
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;
> }
>
syzbot has found a reproducer for the following issue on:
HEAD commit: 8124c8a6 Linux 5.13-rc4
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1047c4a7d00000
kernel config: https://syzkaller.appspot.com/x/.config?x=71698168f5f17484
dashboard link: https://syzkaller.appspot.com/bug?extid=2067e764dbcd10721e2e
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1020b26bd00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12afa2a7d00000
The issue was bisected to:
commit b860eb8dce5906b14e3a7f3c771e0b3d6ef61b94
Author: Fenghua Yu <[email protected]>
Date: Tue May 12 14:54:39 2020 +0000
x86/fpu/xstate: Define new functions for clearing fpregs and xstates
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17c2c723d00000
final oops: https://syzkaller.appspot.com/x/report.txt?x=1422c723d00000
console output: https://syzkaller.appspot.com/x/log.txt?x=1022c723d00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
Fixes: b860eb8dce59 ("x86/fpu/xstate: Define new functions for clearing fpregs and xstates")
syz-executor638[9087] bad frame in rt_sigreturn frame:00007f1dcdbbdbf8 ip:445bf9 sp:7f1dcdbbe188 orax:ffffffffffffffff in syz-executor638076058[401000+9a000]
------------[ cut here ]------------
Bad FPU state detected at copy_kernel_to_xregs arch/x86/include/asm/fpu/internal.h:344 [inline], reinitializing FPU registers.
Bad FPU state detected at __copy_kernel_to_fpregs arch/x86/include/asm/fpu/internal.h:419 [inline], reinitializing FPU registers.
Bad FPU state detected at copy_kernel_to_fpregs arch/x86/include/asm/fpu/internal.h:443 [inline], reinitializing FPU registers.
Bad FPU state detected at __fpregs_load_activate arch/x86/include/asm/fpu/internal.h:514 [inline], reinitializing FPU registers.
Bad FPU state detected at copy_fpstate_to_sigframe+0x4d2/0xae0 arch/x86/kernel/fpu/signal.c:191, reinitializing FPU registers.
WARNING: CPU: 1 PID: 9087 at arch/x86/mm/extable.c:65 ex_handler_fprestore+0xf0/0x110 arch/x86/mm/extable.c:65
Modules linked in:
CPU: 1 PID: 9087 Comm: syz-executor638 Not tainted 5.13.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ex_handler_fprestore+0xf0/0x110 arch/x86/mm/extable.c:65
Code: e8 55 40 40 00 b8 01 00 00 00 5b 5d 41 5c c3 e8 46 40 40 00 48 89 de 48 c7 c7 c0 0c 69 89 c6 05 42 12 81 0c 01 e8 db 48 a1 07 <0f> 0b eb 90 48 89 df e8 94 c8 84 00 e9 3d ff ff ff e8 1a c9 84 00
RSP: 0018:ffffc9000227fa60 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffffff812aeeb2 RCX: 0000000000000000
RDX: ffff88803031a100 RSI: ffffffff815c1805 RDI: fffff5200044ff3e
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815bb63e R11: 0000000000000000 R12: ffffffff8b23f7d8
R13: 000000000000000d R14: 0000000000000000 R15: 0000000000000000
FS: 00007f1dcdbbe700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 0000000031055000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
fixup_exception+0x9a/0xd0 arch/x86/mm/extable.c:183
__exc_general_protection arch/x86/kernel/traps.c:567 [inline]
exc_general_protection+0xed/0x2f0 arch/x86/kernel/traps.c:531
asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:571
RIP: 0010:__fpregs_load_activate arch/x86/include/asm/fpu/internal.h:514 [inline]
RIP: 0010:copy_fpstate_to_sigframe+0x4d2/0xae0 arch/x86/kernel/fpu/signal.c:191
Code: 58 e8 d2 22 49 00 48 c7 c0 c0 29 c9 8d 0f 1f 44 00 00 e8 c1 22 49 00 e8 bc 22 49 00 b8 ff ff ff ff 4c 89 e7 89 c2 48 0f ae 2f <e8> a9 22 49 00 65 4c 89 35 d1 00 d7 7e 0f 1f 44 00 00 e8 97 22 49
RSP: 0018:ffffc9000227fc08 EFLAGS: 00010293
RAX: 00000000ffffffff RBX: ffff88803031a100 RCX: 0000000000000000
RDX: 00000000ffffffff RSI: ffffffff812aeea4 RDI: ffff88803031b900
RBP: ffff88803031a100 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff812aee3b R11: 0000000000000000 R12: ffff88803031b900
R13: ffffed10060636f2 R14: ffff88803031b8c0 R15: 00007f1dcdbbddc0
get_sigframe.constprop.0.isra.0+0x429/0x730 arch/x86/kernel/signal.c:274
__setup_rt_frame arch/x86/kernel/signal.c:450 [inline]
setup_rt_frame arch/x86/kernel/signal.c:702 [inline]
handle_signal arch/x86/kernel/signal.c:746 [inline]
arch_do_signal_or_restart+0xd9e/0x1eb0 arch/x86/kernel/signal.c:791
handle_signal_work kernel/entry/common.c:147 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x171/0x280 kernel/entry/common.c:208
__syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:301
do_syscall_64+0x47/0xb0 arch/x86/entry/common.c:57
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x445bf9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f1dcdbbe188 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 00000000004cb408 RCX: 0000000000445bf9
RDX: 0000000080000002 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00000000004cb400 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004cb40c
R13: 00007ffcd24a5bdf R14: 00007f1dcdbbe300 R15: 0000000000022000