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

[syzbot]

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+401145...@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 syzk...@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

[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.

> ---end quoted text---

[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:

---end quoted text---

[syzbot]

syzbot suspects this issue was fixed by commit:

commit d2c95f9d6802cc518d71d9795f4d9da54fb4e24d
Author: Linus Torvalds <torv...@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

[Linus Torvalds]

[ Added Borislav and stable people ]

On Sun, Apr 30, 2023 at 9:31 PM syzbot
<syzbot+401145...@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

[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. :-\

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