[syzbot] WARNING in fpregs_assert_state_consistent

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: ef6b35306dd8 Add linux-next specific files for 20220204
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14d34d0c700000
kernel config: https://syzkaller.appspot.com/x/.config?x=e0431e0b00810b4f
dashboard link: https://syzkaller.appspot.com/bug?extid=3c0a98026cec79f550a2
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3c0a98...@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3586 at arch/x86/kernel/fpu/core.c:768 fpregs_assert_state_consistent arch/x86/kernel/fpu/core.c:768 [inline]
WARNING: CPU: 0 PID: 3586 at arch/x86/kernel/fpu/core.c:768 fpregs_assert_state_consistent+0x80/0xe0 arch/x86/kernel/fpu/core.c:761
Modules linked in:
CPU: 0 PID: 3586 Comm: syz-fuzzer Not tainted 5.17.0-rc2-next-20220204-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:fpregs_assert_state_consistent arch/x86/kernel/fpu/core.c:768 [inline]
RIP: 0010:fpregs_assert_state_consistent+0x80/0xe0 arch/x86/kernel/fpu/core.c:761
Code: e9 55 ca 4c 00 e8 50 ca 4c 00 e8 db 97 2b 08 89 c3 65 48 8b 05 e9 90 d6 7e 4c 8d a5 80 18 00 00 49 39 c4 74 10 e8 30 ca 4c 00 <0f> 0b 5b 5d 41 5c e9 25 ca 4c 00 e8 20 ca 4c 00 4c 89 e2 48 b8 00
RSP: 0018:ffffc90001acfef0 EFLAGS: 00010093
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88807f2e9d40 RSI: ffffffff812bdec0 RDI: 0000000000000000
RBP: ffff88807f2e9d40 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff812bde8e R11: 0000000000000000 R12: ffff88807f2eb5c0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 000000c000030490(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6371976520 CR3: 000000007f14b000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
arch_exit_to_user_mode_prepare arch/x86/include/asm/entry-common.h:56 [inline]
exit_to_user_mode_prepare+0x57/0x290 kernel/entry/common.c:209
__syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x5edb02
Code: cc cc cc cc cc cc cc cc 49 3b 66 10 0f 86 fd 01 00 00 48 83 ec 48 48 89 6c 24 40 48 8d 6c 24 40 48 89 44 24 50 48 89 5c 24 58 <48> 8b 13 48 8b 70 20 8b 78 18 eb 06 48 89 fa 44 89 c7 48 89 54 24
RSP: 002b:000000c000241b28 EFLAGS: 00000216
RAX: 000000c0006c4000 RBX: 000000c0006c4028 RCX: 00000000000032c6
RDX: 0000000000008000 RSI: 000000c0006c4000 RDI: 0000000000000009
RBP: 000000c000241b68 R08: 00000000000032c5 R09: 000000c0006ca000
R10: 0000000000004d3b R11: 0000000000003250 R12: 0000000000002000
R13: 0000000000002dab R14: 000000c00029aea0 R15: 0000000000000002
</TASK>


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[Dave Hansen]

On 2/8/22 00:31, syzbot wrote:
> Call Trace:
> <TASK>
> arch_exit_to_user_mode_prepare arch/x86/include/asm/entry-common.h:56 [inline]
> exit_to_user_mode_prepare+0x57/0x290 kernel/entry/common.c:209
> __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
> syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
> do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
> entry_SYSCALL_64_after_hwframe+0x44/0xae

Just in case it saves anyone else the trouble...

This is a WARN_ON_FPU() that triggers inside
fpregs_assert_state_consistent() because TIF_NEED_FPU_LOAD is clear
while !fpregs_state_valid().

In other words, the FPU registers are *in*valid, but they're also not
marked to be reloaded. They must be valid before returning to userspace.

The stack trace is not very helpful because it's almost empty on the
return to userspace.

I don't see anything x86-FPU-specific between 5.17-rc2 and the
linux-next commit in question.

I think we need to wait on a reproducer or a more revealing warning.

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.