Re: [syzbot] [ntfs3?] [btrfs?] BUG: unable to handle kernel paging request in clear_user_rep_good

Re: [syzbot] [ntfs3?] [btrfs?] BUG: unable to handle kernel paging request in clear_user_rep_good

[Christoph Hellwig]

Where are the ntfs3 and btrfs tags coming from?  This seems to clearly
be about ext4 in the call stack.

On Thu, Feb 02, 2023 at 11:54:48PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    ab072681eabe Merge tag 'irq_urgent_for_v6.2_rc6' of git://..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15933749480000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=23330449ad10b66f
> dashboard link: https://syzkaller.appspot.com/bug?extid=401145a9a237779feb26
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13b3ba9e480000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/a43bbc272cf3/disk-ab072681.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/fec05f5bcfa7/vmlinux-ab072681.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/00b9b0dd9801/bzImage-ab072681.xz
> mounted in repro #1: https://storage.googleapis.com/syzbot-assets/f7ef8856a9ce/mount_0.gz
> mounted in repro #2: https://storage.googleapis.com/syzbot-assets/79f8035a08dd/mount_4.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+401145a9a237779feb26@syzkaller.appspotmail.com
> 
> BUG: unable to handle page fault for address: 0000000020081000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 1c9cc067 P4D 1c9cc067 PUD 280e9067 PMD 2a76b067 PTE 0
> Oops: 0002 [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 5441 Comm: syz-executor.1 Not tainted 6.2.0-rc5-syzkaller-00221-gab072681eabe #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147
> Code: 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 83 f9 40 72 a6 89 ca 48 c1 e9 03 74 03 f3 48 ab 83 e2 07 74 04 89 d1 <f3> aa 31 c0 c3 48 c1 e1 03 83 e2 07 48 01 d1 eb f1 0f 1f 00 f3 0f
> RSP: 0018:ffffc900056f76d8 EFLAGS: 00050202
> RAX: 0000000000000000 RBX: 0000000000081002 RCX: 0000000000000002
> RDX: 0000000000000002 RSI: ffffffff84098c49 RDI: 0000000020081000
> RBP: 0000000000081002 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000094001 R12: ffffc900056f7d70
> R13: 0000000020000000 R14: 000000007ffff000 R15: 0000000000000000
> FS:  00007fc1837f1700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020081000 CR3: 000000002b26e000 CR4: 0000000000350ef0
> Call Trace:
>  <TASK>
>  __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]
>  clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]
>  iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800
>  iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]
>  iomap_dio_iter fs/iomap/direct-io.c:440 [inline]
>  __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601
>  iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689
>  ext4_dio_read_iter fs/ext4/file.c:94 [inline]
>  ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145
>  call_read_iter include/linux/fs.h:2183 [inline]
>  do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733
>  do_iter_read+0x2f2/0x750 fs/read_write.c:796
>  vfs_readv+0xe5/0x150 fs/read_write.c:916
>  do_preadv+0x1b6/0x270 fs/read_write.c:1008
>  __do_sys_preadv2 fs/read_write.c:1070 [inline]
>  __se_sys_preadv2 fs/read_write.c:1061 [inline]
>  __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7fc182a8c0c9
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fc1837f1168 EFLAGS: 00000246 ORIG_RAX: 0000000000000147
> RAX: ffffffffffffffda RBX: 00007fc182babf80 RCX: 00007fc182a8c0c9
> RDX: 0000000000000001 RSI: 0000000020000100 RDI: 0000000000000003
> RBP: 00007fc182ae7ae9 R08: 0000000000000000 R09: 0000000000000000
> R10: 000000000007fffe R11: 0000000000000246 R12: 0000000000000000
> R13: 00007ffefd64d1ef R14: 00007fc1837f1300 R15: 0000000000022000
>  </TASK>
> Modules linked in:
> CR2: 0000000020081000
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147
> Code: 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 83 f9 40 72 a6 89 ca 48 c1 e9 03 74 03 f3 48 ab 83 e2 07 74 04 89 d1 <f3> aa 31 c0 c3 48 c1 e1 03 83 e2 07 48 01 d1 eb f1 0f 1f 00 f3 0f
> RSP: 0018:ffffc900056f76d8 EFLAGS: 00050202
> RAX: 0000000000000000 RBX: 0000000000081002 RCX: 0000000000000002
> RDX: 0000000000000002 RSI: ffffffff84098c49 RDI: 0000000020081000
> RBP: 0000000000081002 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000094001 R12: ffffc900056f7d70
> R13: 0000000020000000 R14: 000000007ffff000 R15: 0000000000000000
> FS:  00007fc1837f1700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f8294a2a000 CR3: 000000002b26e000 CR4: 0000000000350ef0
> ----------------
> Code disassembly (best guess):
>    0:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>    7:	00 00 00 00
>    b:	0f 1f 00             	nopl   (%rax)
>    e:	f3 0f 1e fa          	endbr64
>   12:	48 83 f9 40          	cmp    $0x40,%rcx
>   16:	72 a6                	jb     0xffffffbe
>   18:	89 ca                	mov    %ecx,%edx
>   1a:	48 c1 e9 03          	shr    $0x3,%rcx
>   1e:	74 03                	je     0x23
>   20:	f3 48 ab             	rep stos %rax,%es:(%rdi)
>   23:	83 e2 07             	and    $0x7,%edx
>   26:	74 04                	je     0x2c
>   28:	89 d1                	mov    %edx,%ecx
> * 2a:	f3 aa                	rep stos %al,%es:(%rdi) <-- trapping instruction
>   2c:	31 c0                	xor    %eax,%eax
>   2e:	c3                   	retq
>   2f:	48 c1 e1 03          	shl    $0x3,%rcx
>   33:	83 e2 07             	and    $0x7,%edx
>   36:	48 01 d1             	add    %rdx,%rcx
>   39:	eb f1                	jmp    0x2c
>   3b:	0f 1f 00             	nopl   (%rax)
>   3e:	f3                   	repz
>   3f:	0f                   	.byte 0xf
> 
> 
> ---
> 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 syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
---end quoted text---

Re: [syzbot] [ntfs3?] [btrfs?] BUG: unable to handle kernel paging request in clear_user_rep_good

[Matthew Wilcox]

On Fri, Feb 03, 2023 at 08:25:32AM -0800, Christoph Hellwig wrote:
> Where are the ntfs3 and btrfs tags coming from?  This seems to clearly
> be about ext4 in the call stack.

I believe if you look at the reproducer, ext4 is the target of the DIO,
but the source is a mmaped file on a corrupted ntfs3 image.  Or maybe
btrfs; it's created two images.

> On Thu, Feb 02, 2023 at 11:54:48PM -0800, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    ab072681eabe Merge tag 'irq_urgent_for_v6.2_rc6' of git://..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15933749480000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=23330449ad10b66f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=401145a9a237779feb26
> > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13b3ba9e480000
> > 
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/a43bbc272cf3/disk-ab072681.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/fec05f5bcfa7/vmlinux-ab072681.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/00b9b0dd9801/bzImage-ab072681.xz
> > mounted in repro #1: https://storage.googleapis.com/syzbot-assets/f7ef8856a9ce/mount_0.gz
> > mounted in repro #2: https://storage.googleapis.com/syzbot-assets/79f8035a08dd/mount_4.gz
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+401145a9a237779feb26@syzkaller.appspotmail.com
> > 
> > BUG: unable to handle page fault for address: 0000000020081000
> > #PF: supervisor write access in kernel mode
> > #PF: error_code(0x0002) - not-present page
> > PGD 1c9cc067 P4D 1c9cc067 PUD 280e9067 PMD 2a76b067 PTE 0
> > Oops: 0002 [#1] PREEMPT SMP KASAN
> > CPU: 0 PID: 5441 Comm: syz-executor.1 Not tainted 6.2.0-rc5-syzkaller-00221-gab072681eabe #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> > RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147
> > Code: 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 83 f9 40 72 a6 89 ca 48 c1 e9 03 74 03 f3 48 ab 83 e2 07 74 04 89 d1 <f3> aa 31 c0 c3 48 c1 e1 03 83 e2 07 48 01 d1 eb f1 0f 1f 00 f3 0f
> > RSP: 0018:ffffc900056f76d8 EFLAGS: 00050202
> > RAX: 0000000000000000 RBX: 0000000000081002 RCX: 0000000000000002
> > RDX: 0000000000000002 RSI: ffffffff84098c49 RDI: 0000000020081000
> > RBP: 0000000000081002 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000001 R11: 0000000000094001 R12: ffffc900056f7d70
> > R13: 0000000020000000 R14: 000000007ffff000 R15: 0000000000000000
> > FS:  00007fc1837f1700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000020081000 CR3: 000000002b26e000 CR4: 0000000000350ef0
> > Call Trace:
> >  <TASK>
> >  __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]
> >  clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]
> >  iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800
> >  iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]
> >  iomap_dio_iter fs/iomap/direct-io.c:440 [inline]
> >  __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601
> >  iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689
> >  ext4_dio_read_iter fs/ext4/file.c:94 [inline]
> >  ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145
> >  call_read_iter include/linux/fs.h:2183 [inline]
> >  do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733
> >  do_iter_read+0x2f2/0x750 fs/read_write.c:796
> >  vfs_readv+0xe5/0x150 fs/read_write.c:916
> >  do_preadv+0x1b6/0x270 fs/read_write.c:1008
> >  __do_sys_preadv2 fs/read_write.c:1070 [inline]
> >  __se_sys_preadv2 fs/read_write.c:1061 [inline]
> >  __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061
> >  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> >  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
> >  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > RIP: 0033:0x7fc182a8c0c9
> > Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 b8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007fc1837f1168 EFLAGS: 00000246 ORIG_RAX: 0000000000000147
> > RAX: ffffffffffffffda RBX: 00007fc182babf80 RCX: 00007fc182a8c0c9
> > RDX: 0000000000000001 RSI: 0000000020000100 RDI: 0000000000000003
> > RBP: 00007fc182ae7ae9 R08: 0000000000000000 R09: 0000000000000000
> > R10: 000000000007fffe R11: 0000000000000246 R12: 0000000000000000
> > R13: 00007ffefd64d1ef R14: 00007fc1837f1300 R15: 0000000000022000
> >  </TASK>
> > Modules linked in:
> > CR2: 0000000020081000
> > ---[ end trace 0000000000000000 ]---
> > RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147
> > Code: 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 83 f9 40 72 a6 89 ca 48 c1 e9 03 74 03 f3 48 ab 83 e2 07 74 04 89 d1 <f3> aa 31 c0 c3 48 c1 e1 03 83 e2 07 48 01 d1 eb f1 0f 1f 00 f3 0f
> > RSP: 0018:ffffc900056f76d8 EFLAGS: 00050202
> > RAX: 0000000000000000 RBX: 0000000000081002 RCX: 0000000000000002
> > RDX: 0000000000000002 RSI: ffffffff84098c49 RDI: 0000000020081000
> > RBP: 0000000000081002 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000001 R11: 0000000000094001 R12: ffffc900056f7d70
> > R13: 0000000020000000 R14: 000000007ffff000 R15: 0000000000000000
> > FS:  00007fc1837f1700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f8294a2a000 CR3: 000000002b26e000 CR4: 0000000000350ef0
> > ----------------
> > Code disassembly (best guess):
> >    0:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
> >    7:	00 00 00 00
> >    b:	0f 1f 00             	nopl   (%rax)
> >    e:	f3 0f 1e fa          	endbr64
> >   12:	48 83 f9 40          	cmp    $0x40,%rcx
> >   16:	72 a6                	jb     0xffffffbe
> >   18:	89 ca                	mov    %ecx,%edx
> >   1a:	48 c1 e9 03          	shr    $0x3,%rcx
> >   1e:	74 03                	je     0x23
> >   20:	f3 48 ab             	rep stos %rax,%es:(%rdi)
> >   23:	83 e2 07             	and    $0x7,%edx
> >   26:	74 04                	je     0x2c
> >   28:	89 d1                	mov    %edx,%ecx
> > * 2a:	f3 aa                	rep stos %al,%es:(%rdi) <-- trapping instruction
> >   2c:	31 c0                	xor    %eax,%eax
> >   2e:	c3                   	retq
> >   2f:	48 c1 e1 03          	shl    $0x3,%rcx
> >   33:	83 e2 07             	and    $0x7,%edx
> >   36:	48 01 d1             	add    %rdx,%rcx
> >   39:	eb f1                	jmp    0x2c
> >   3b:	0f 1f 00             	nopl   (%rax)
> >   3e:	f3                   	repz
> >   3f:	0f                   	.byte 0xf
> > 
> > 
> > ---
> > 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 syzkaller@googlegroups.com.
> > 
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > syzbot can test patches for this issue, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
> ---end quoted text---

Re: [syzbot] [xfs?] BUG: unable to handle kernel paging request in clear_user_rep_good

[syzbot]

syzbot suspects this issue was fixed by commit:

commit d2c95f9d6802cc518d71d9795f4d9da54fb4e24d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Apr 15 20:22:31 2023 +0000

    x86: don't use REP_GOOD or ERMS for user memory clearing

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13636ffc280000
start commit:   ab072681eabe Merge tag 'irq_urgent_for_v6.2_rc6' of git://..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=23330449ad10b66f
dashboard link: https://syzkaller.appspot.com/bug?extid=401145a9a237779feb26
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13b3ba9e480000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: x86: don't use REP_GOOD or ERMS for user memory clearing

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [xfs?] BUG: unable to handle kernel paging request in clear_user_rep_good

[Linus Torvalds]

[ Added Borislav and stable people ]

On Sun, Apr 30, 2023 at 9:31 PM syzbot
<syzbot+401145a9a237779feb26@syzkaller.appspotmail.com> wrote:
>
> syzbot suspects this issue was fixed by commit:

Indeed.

My initial reaction was "no, that didn't fix anything, it just cleaned
stuff up", but it turns out that yes, it did in fact fix a real bug in
the process.

The fix was not intentional, but the cleanup actually got rid of buggy code.

So here's the automatic marker for syzbot:

#syz fix: x86: don't use REP_GOOD or ERMS for user memory clearing

and the reason for the bug - in case people care - is that the old
clear_user_rep_good (which no longer exists after that commit) had the
exception entry pointing to the wrong instruction.

The buggy code did:

    .Lrep_good_bytes:
            mov %edx, %ecx
            rep stosb

and the exception entry weas

        _ASM_EXTABLE_UA(.Lrep_good_bytes, .Lrep_good_exit)

so the exception entry pointed at the register move instruction, not
at the actual "rep stosb" that does the user space store.

End result: if you had a situation where you *should* return -EFAULT,
and you triggered that "last final bytes" case, instead of the
exception handling dealing with it properly and fixing it up, you got
that kernel oops.

The bug goes back to commit 0db7058e8e23 ("x86/clear_user: Make it
faster") from about a year ago, which made it into v6.1.

It only affects old hardware that doesn't have the ERMS capability
flag, which *probably* means that it's mostly only triggerable in
virtualization (since pretty much any CPU from the last decade has
ERMS, afaik).

Borislav - opinions? This needs fixing for v6.1..v6.3, and the options are:

 (1) just fix up the exception entry. I think this is literally this
one-liner, but somebody should double-check me. I did *not* actually
test this:

    --- a/arch/x86/lib/clear_page_64.S
    +++ b/arch/x86/lib/clear_page_64.S
    @@ -142,8 +142,8 @@ SYM_FUNC_START(clear_user_rep_good)
            and $7, %edx
            jz .Lrep_good_exit

    -.Lrep_good_bytes:
            mov %edx, %ecx
    +.Lrep_good_bytes:
            rep stosb

     .Lrep_good_exit:

   because the only use of '.Lrep_good_bytes' is that exception table entry.

 (2) backport just that one commit for clear_user

     In this case we should probably do commit e046fe5a36a9 ("x86: set
FSRS automatically on AMD CPUs that have FSRM") too, since that commit
changes the decision to use 'rep stosb' to check FSRS.

 (3) backport the entire series of commits:

        git log --oneline v6.3..034ff37d3407

Or we could even revert that commit 0db7058e8e23, but it seems silly
to revert when we have so many ways to fix it, including a one-line
code movement.

Borislav / stable people? Opinions?

                         Linus

Re: [syzbot] [xfs?] BUG: unable to handle kernel paging request in clear_user_rep_good

[Borislav Petkov]

On Mon, May 01, 2023 at 11:49:55AM -0700, Linus Torvalds wrote:
> The bug goes back to commit 0db7058e8e23 ("x86/clear_user: Make it
> faster") from about a year ago, which made it into v6.1.

Gah, sorry about that. :-\

> It only affects old hardware that doesn't have the ERMS capability
> flag, which *probably* means that it's mostly only triggerable in
> virtualization (since pretty much any CPU from the last decade has
> ERMS, afaik).
> 
> Borislav - opinions? This needs fixing for v6.1..v6.3, and the options are:
> 
>  (1) just fix up the exception entry. I think this is literally this
> one-liner, but somebody should double-check me. I did *not* actually
> test this:
> 
>     --- a/arch/x86/lib/clear_page_64.S
>     +++ b/arch/x86/lib/clear_page_64.S
>     @@ -142,8 +142,8 @@ SYM_FUNC_START(clear_user_rep_good)
>             and $7, %edx
>             jz .Lrep_good_exit
> 
>     -.Lrep_good_bytes:
>             mov %edx, %ecx
>     +.Lrep_good_bytes:
>             rep stosb
> 
>      .Lrep_good_exit:
> 
>    because the only use of '.Lrep_good_bytes' is that exception table entry.
> 
>  (2) backport just that one commit for clear_user
> 
>      In this case we should probably do commit e046fe5a36a9 ("x86: set
> FSRS automatically on AMD CPUs that have FSRM") too, since that commit
> changes the decision to use 'rep stosb' to check FSRS.
> 
>  (3) backport the entire series of commits:
> 
>         git log --oneline v6.3..034ff37d3407
> 
> Or we could even revert that commit 0db7058e8e23, but it seems silly
> to revert when we have so many ways to fix it, including a one-line
> code movement.
> 
> Borislav / stable people? Opinions?

So right now I feel like (3) would be the right thing to do. Because
then stable and upstream will be on the same "level" wrt user-accessing
primitives. And it's not like your series depend on anything from
mainline (that I know of) so backporting them should be relatively easy.

But (1) is definitely a lot easier for stable people modulo the fact
that it won't be an upstream commit but a special stable-only fix.

So yeah, in that order.

I guess I'd let stable people decide here what they wanna do.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette