[syzbot] [mm?] BUG: unable to handle kernel paging request in bpf_probe_read_compat_str

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: dbc153fd3c14 net/smc: fix illegal rmb_desc access in SMC-D..
git tree: net
console+strace: https://syzkaller.appspot.com/x/log.txt?x=111f4053e80000
kernel config: https://syzkaller.appspot.com/x/.config?x=719e6acaf392d56b
dashboard link: https://syzkaller.appspot.com/bug?extid=239f12e20785af44332c
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1174113be80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15065573e80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/03c4609fe0f7/disk-dbc153fd.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0d96e02c115d/vmlinux-dbc153fd.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3acdf2bb45e3/bzImage-dbc153fd.xz

The issue was bisected to:

commit ca247283781d754216395a41c5e8be8ec79a5f1c
Author: Andy Lutomirski <lu...@kernel.org>
Date: Wed Feb 10 02:33:45 2021 +0000

x86/fault: Don't run fixups for SMAP violations

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16ba553be80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=15ba553be80000
console output: https://syzkaller.appspot.com/x/log.txt?x=11ba553be80000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+239f12...@syzkaller.appspotmail.com
Fixes: ca247283781d ("x86/fault: Don't run fixups for SMAP violations")

BUG: unable to handle page fault for address: ffffffffff600000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD cf7b067 P4D cf7b067 PUD cf7d067 PMD cfa0067 PTE 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 5063 Comm: syz-executor178 Not tainted 6.7.0-syzkaller-12263-gdbc153fd3c14 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
RIP: 0010:strncpy_from_kernel_nofault+0xc4/0x270 mm/maccess.c:91
Code: 83 85 6c 17 00 00 01 48 8b 2c 24 eb 18 e8 84 76 ce ff 4c 89 f6 4c 89 ef e8 89 71 ce ff 4d 39 f5 7d 5c 4c 89 fb e8 6c 76 ce ff <44> 8a 65 00 e8 63 76 ce ff 48 89 d8 48 89 da 48 b9 00 00 00 00 00
RSP: 0018:ffffc90003a6f990 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffffc90003a6fa00 RCX: ffffffff81b9aaa2
RDX: ffff888028743b80 RSI: ffffffff81b9ab14 RDI: ffff8880287452ec
RBP: ffffffffff600000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000008
R13: ffffffffff600000 R14: 0000000000000008 R15: ffffffffff600000
FS: 00005555560c2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600000 CR3: 000000007a3e2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
bpf_probe_read_kernel_str_common kernel/trace/bpf_trace.c:266 [inline]
____bpf_probe_read_compat_str kernel/trace/bpf_trace.c:314 [inline]
bpf_probe_read_compat_str+0x12f/0x170 kernel/trace/bpf_trace.c:307
bpf_prog_f17ebaf3f5f7baf8+0x42/0x44
bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
__bpf_prog_run include/linux/filter.h:651 [inline]
bpf_prog_run include/linux/filter.h:658 [inline]
__bpf_trace_run kernel/trace/bpf_trace.c:2381 [inline]
bpf_trace_run4+0x173/0x450 kernel/trace/bpf_trace.c:2422
__bpf_trace_sched_switch+0x13e/0x180 include/trace/events/sched.h:222
trace_sched_switch include/trace/events/sched.h:222 [inline]
__schedule+0x2235/0x5c00 kernel/sched/core.c:6724
__schedule_loop kernel/sched/core.c:6802 [inline]
schedule+0xe9/0x270 kernel/sched/core.c:6817
ptrace_stop.part.0+0x44d/0x950 kernel/signal.c:2344
ptrace_stop kernel/signal.c:2246 [inline]
ptrace_do_notify+0x226/0x2d0 kernel/signal.c:2381
ptrace_notify+0xc8/0x130 kernel/signal.c:2393
ptrace_report_syscall include/linux/ptrace.h:411 [inline]
ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]
syscall_exit_work kernel/entry/common.c:167 [inline]
syscall_exit_to_user_mode_prepare+0x126/0x230 kernel/entry/common.c:194
__syscall_exit_to_user_mode_work kernel/entry/common.c:199 [inline]
syscall_exit_to_user_mode+0x11/0x2b0 kernel/entry/common.c:212
do_syscall_64+0xe0/0x250 arch/x86/entry/common.c:89
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f69162d5b39
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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:00007ffc7c688218 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: 0000000000000004 RBX: 0000000000000000 RCX: 00007f69162d5b39
RDX: 0000000000000010 RSI: 0000000020000280 RDI: 0000000000000011
RBP: 0000000000000000 R08: 0000000000000006 R09: 0000000000000006
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000003a28
R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
</TASK>
Modules linked in:
CR2: ffffffffff600000
---[ end trace 0000000000000000 ]---
RIP: 0010:strncpy_from_kernel_nofault+0xc4/0x270 mm/maccess.c:91
Code: 83 85 6c 17 00 00 01 48 8b 2c 24 eb 18 e8 84 76 ce ff 4c 89 f6 4c 89 ef e8 89 71 ce ff 4d 39 f5 7d 5c 4c 89 fb e8 6c 76 ce ff <44> 8a 65 00 e8 63 76 ce ff 48 89 d8 48 89 da 48 b9 00 00 00 00 00
RSP: 0018:ffffc90003a6f990 EFLAGS: 00010093

RAX: 0000000000000000 RBX: ffffc90003a6fa00 RCX: ffffffff81b9aaa2
RDX: ffff888028743b80 RSI: ffffffff81b9ab14 RDI: ffff8880287452ec
RBP: ffffffffff600000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000008
R13: ffffffffff600000 R14: 0000000000000008 R15: ffffffffff600000
FS: 00005555560c2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600000 CR3: 000000007a3e2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 83 85 6c 17 00 00 01 addl $0x1,0x176c(%rbp)
7: 48 8b 2c 24 mov (%rsp),%rbp
b: eb 18 jmp 0x25
d: e8 84 76 ce ff call 0xffce7696
12: 4c 89 f6 mov %r14,%rsi
15: 4c 89 ef mov %r13,%rdi
18: e8 89 71 ce ff call 0xffce71a6
1d: 4d 39 f5 cmp %r14,%r13
20: 7d 5c jge 0x7e
22: 4c 89 fb mov %r15,%rbx
25: e8 6c 76 ce ff call 0xffce7696
* 2a: 44 8a 65 00 mov 0x0(%rbp),%r12b <-- trapping instruction
2e: e8 63 76 ce ff call 0xffce7696
33: 48 89 d8 mov %rbx,%rax
36: 48 89 da mov %rbx,%rdx
39: 48 rex.W
3a: b9 00 00 00 00 mov $0x0,%ecx


---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Guilherme G. Piccoli]

Hi folks, I've been trying to play with this report and was able to
reproduce on v6.8-rc2, in a simple qemu VM.

But the thing is: after looking similar reports in MLs, this seems quite
the same report as [0], so a dup. And we even have a candidate fix for
it, in the form of Thomas's patch
(https://lore.kernel.org/all/87r0jwquhv.ffs@tglx/). I've tested this
patch and it works, preventing the crash.

So...

Jann: could you help me confirm the reproducer here is the same of the
other report, in which you nailed it to accessing the VSYSCALL region?
For me it's quite similar, but I'm not experienced in reading this kind
of BPF program...

Thomas: could you maybe re-submit/merge this patch, if you still agree
this is the proper fix? There's a Tested-by from Hou Tao in that thread,
and feel free to add mine as well!

Thanks in advance and let me know if I can test more stuff / provide
more data, etc - I'm glad to help here.
Cheers,


Guilherme


[0] https://lore.kernel.org/all/000000000000c8...@google.com/
("[syzbot] [mm?] BUG: unable to handle kernel paging request in
copy_from_kernel_nofault")