* [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-10 18:28 syzbot 2021-03-10 18:53 ` Dmitry Vyukov 0 siblings, 1 reply; 19+ messages in thread From: syzbot @ 2021-03-10 18:28 UTC (permalink / raw) To: andrii, ast, bpf, daniel, davem, john.fastabend, kafai, kpsingh, kuba, linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs Hello, syzbot found the following issue on: HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 userspace arch: riscv64 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+c23c5421600e9b454849@syzkaller.appspotmail.com Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000020000300 Oops [#1] Modules linked in: CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 Hardware name: riscv-virtio,qemu (DT) epc : sock_ioctl+0x424/0x6ac net/socket.c:1124 ra : sock_ioctl+0x424/0x6ac net/socket.c:1124 epc : ffffffe002aeeb3e ra : ffffffe002aeeb3e sp : ffffffe023867da0 gp : ffffffe005d25378 tp : ffffffe007e116c0 t0 : 0000000000000000 t1 : 0000000000000001 t2 : 0000003fb8035e44 s0 : ffffffe023867e30 s1 : 0000000000040000 a0 : 0000000000000000 a1 : 0000000000000007 a2 : 1ffffffc00fc22d8 a3 : ffffffe003bc1d02 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba s2 : 0000000000000000 s3 : 0000000000008902 s4 : 0000000020000300 s5 : ffffffe005d2b0d0 s6 : ffffffe010facfc0 s7 : ffffffe008e00000 s8 : 0000000000008903 s9 : ffffffe010fad080 s10: 0000000000000000 s11: 0000000000020000 t3 : 982de389919f6300 t4 : ffffffc401175688 t5 : ffffffc401175691 t6 : 0000000000000007 status: 0000000000000120 badaddr: 0000000020000300 cause: 000000000000000f Call Trace: [<ffffffe002aeeb3e>] sock_ioctl+0x424/0x6ac net/socket.c:1124 [<ffffffe0003fdb6a>] vfs_ioctl fs/ioctl.c:48 [inline] [<ffffffe0003fdb6a>] __do_sys_ioctl fs/ioctl.c:753 [inline] [<ffffffe0003fdb6a>] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739 [<ffffffe000005562>] ret_from_syscall+0x0/0x2 Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace a5f91e70f37b907b ]--- --- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-10 18:28 [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl syzbot @ 2021-03-10 18:53 ` Dmitry Vyukov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-10 18:53 UTC (permalink / raw) To: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Wed, Mar 10, 2021 at 7:28 PM syzbot <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > userspace arch: riscv64 > > 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+c23c5421600e9b454849@syzkaller.appspotmail.com +riscv maintainers Another case of put_user crashing. > Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000020000300 > Oops [#1] > Modules linked in: > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 > Hardware name: riscv-virtio,qemu (DT) > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124 > ra : sock_ioctl+0x424/0x6ac net/socket.c:1124 > epc : ffffffe002aeeb3e ra : ffffffe002aeeb3e sp : ffffffe023867da0 > gp : ffffffe005d25378 tp : ffffffe007e116c0 t0 : 0000000000000000 > t1 : 0000000000000001 t2 : 0000003fb8035e44 s0 : ffffffe023867e30 > s1 : 0000000000040000 a0 : 0000000000000000 a1 : 0000000000000007 > a2 : 1ffffffc00fc22d8 a3 : ffffffe003bc1d02 a4 : 0000000000000000 > a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba > s2 : 0000000000000000 s3 : 0000000000008902 s4 : 0000000020000300 > s5 : ffffffe005d2b0d0 s6 : ffffffe010facfc0 s7 : ffffffe008e00000 > s8 : 0000000000008903 s9 : ffffffe010fad080 s10: 0000000000000000 > s11: 0000000000020000 t3 : 982de389919f6300 t4 : ffffffc401175688 > t5 : ffffffc401175691 t6 : 0000000000000007 > status: 0000000000000120 badaddr: 0000000020000300 cause: 000000000000000f > Call Trace: > [<ffffffe002aeeb3e>] sock_ioctl+0x424/0x6ac net/socket.c:1124 > [<ffffffe0003fdb6a>] vfs_ioctl fs/ioctl.c:48 [inline] > [<ffffffe0003fdb6a>] __do_sys_ioctl fs/ioctl.c:753 [inline] > [<ffffffe0003fdb6a>] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739 > [<ffffffe000005562>] ret_from_syscall+0x0/0x2 > Dumping ftrace buffer: > (ftrace buffer empty) > ---[ end trace a5f91e70f37b907b ]--- > > > --- > 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. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000096cdaa05bd32d46f%40google.com. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-10 18:53 ` Dmitry Vyukov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-10 18:53 UTC (permalink / raw) To: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Wed, Mar 10, 2021 at 7:28 PM syzbot <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > userspace arch: riscv64 > > 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+c23c5421600e9b454849@syzkaller.appspotmail.com +riscv maintainers Another case of put_user crashing. > Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000020000300 > Oops [#1] > Modules linked in: > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 > Hardware name: riscv-virtio,qemu (DT) > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124 > ra : sock_ioctl+0x424/0x6ac net/socket.c:1124 > epc : ffffffe002aeeb3e ra : ffffffe002aeeb3e sp : ffffffe023867da0 > gp : ffffffe005d25378 tp : ffffffe007e116c0 t0 : 0000000000000000 > t1 : 0000000000000001 t2 : 0000003fb8035e44 s0 : ffffffe023867e30 > s1 : 0000000000040000 a0 : 0000000000000000 a1 : 0000000000000007 > a2 : 1ffffffc00fc22d8 a3 : ffffffe003bc1d02 a4 : 0000000000000000 > a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba > s2 : 0000000000000000 s3 : 0000000000008902 s4 : 0000000020000300 > s5 : ffffffe005d2b0d0 s6 : ffffffe010facfc0 s7 : ffffffe008e00000 > s8 : 0000000000008903 s9 : ffffffe010fad080 s10: 0000000000000000 > s11: 0000000000020000 t3 : 982de389919f6300 t4 : ffffffc401175688 > t5 : ffffffc401175691 t6 : 0000000000000007 > status: 0000000000000120 badaddr: 0000000020000300 cause: 000000000000000f > Call Trace: > [<ffffffe002aeeb3e>] sock_ioctl+0x424/0x6ac net/socket.c:1124 > [<ffffffe0003fdb6a>] vfs_ioctl fs/ioctl.c:48 [inline] > [<ffffffe0003fdb6a>] __do_sys_ioctl fs/ioctl.c:753 [inline] > [<ffffffe0003fdb6a>] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739 > [<ffffffe000005562>] ret_from_syscall+0x0/0x2 > Dumping ftrace buffer: > (ftrace buffer empty) > ---[ end trace a5f91e70f37b907b ]--- > > > --- > 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. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000096cdaa05bd32d46f%40google.com. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-10 18:53 ` Dmitry Vyukov @ 2021-03-14 10:01 ` Dmitry Vyukov -1 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-14 10:01 UTC (permalink / raw) To: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Wed, Mar 10, 2021 at 7:53 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, Mar 10, 2021 at 7:28 PM syzbot > <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > > dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > > userspace arch: riscv64 > > > > 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+c23c5421600e9b454849@syzkaller.appspotmail.com > > +riscv maintainers > > Another case of put_user crashing. There are 58 crashes in sock_ioctl already. Somehow there is a very significant skew towards crashing with this "user memory without uaccess routines" in schedule_tail and sock_ioctl of all places in the kernel that use put_user... This looks very strange... Any ideas what's special about these 2 locations? > > Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000020000300 > > Oops [#1] > > Modules linked in: > > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 > > Hardware name: riscv-virtio,qemu (DT) > > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > ra : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > epc : ffffffe002aeeb3e ra : ffffffe002aeeb3e sp : ffffffe023867da0 > > gp : ffffffe005d25378 tp : ffffffe007e116c0 t0 : 0000000000000000 > > t1 : 0000000000000001 t2 : 0000003fb8035e44 s0 : ffffffe023867e30 > > s1 : 0000000000040000 a0 : 0000000000000000 a1 : 0000000000000007 > > a2 : 1ffffffc00fc22d8 a3 : ffffffe003bc1d02 a4 : 0000000000000000 > > a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba > > s2 : 0000000000000000 s3 : 0000000000008902 s4 : 0000000020000300 > > s5 : ffffffe005d2b0d0 s6 : ffffffe010facfc0 s7 : ffffffe008e00000 > > s8 : 0000000000008903 s9 : ffffffe010fad080 s10: 0000000000000000 > > s11: 0000000000020000 t3 : 982de389919f6300 t4 : ffffffc401175688 > > t5 : ffffffc401175691 t6 : 0000000000000007 > > status: 0000000000000120 badaddr: 0000000020000300 cause: 000000000000000f > > Call Trace: > > [<ffffffe002aeeb3e>] sock_ioctl+0x424/0x6ac net/socket.c:1124 > > [<ffffffe0003fdb6a>] vfs_ioctl fs/ioctl.c:48 [inline] > > [<ffffffe0003fdb6a>] __do_sys_ioctl fs/ioctl.c:753 [inline] > > [<ffffffe0003fdb6a>] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739 > > [<ffffffe000005562>] ret_from_syscall+0x0/0x2 > > Dumping ftrace buffer: > > (ftrace buffer empty) > > ---[ end trace a5f91e70f37b907b ]--- > > > > > > --- > > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-14 10:01 ` Dmitry Vyukov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-14 10:01 UTC (permalink / raw) To: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Wed, Mar 10, 2021 at 7:53 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, Mar 10, 2021 at 7:28 PM syzbot > <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > > dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > > userspace arch: riscv64 > > > > 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+c23c5421600e9b454849@syzkaller.appspotmail.com > > +riscv maintainers > > Another case of put_user crashing. There are 58 crashes in sock_ioctl already. Somehow there is a very significant skew towards crashing with this "user memory without uaccess routines" in schedule_tail and sock_ioctl of all places in the kernel that use put_user... This looks very strange... Any ideas what's special about these 2 locations? > > Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000020000300 > > Oops [#1] > > Modules linked in: > > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 > > Hardware name: riscv-virtio,qemu (DT) > > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > ra : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > epc : ffffffe002aeeb3e ra : ffffffe002aeeb3e sp : ffffffe023867da0 > > gp : ffffffe005d25378 tp : ffffffe007e116c0 t0 : 0000000000000000 > > t1 : 0000000000000001 t2 : 0000003fb8035e44 s0 : ffffffe023867e30 > > s1 : 0000000000040000 a0 : 0000000000000000 a1 : 0000000000000007 > > a2 : 1ffffffc00fc22d8 a3 : ffffffe003bc1d02 a4 : 0000000000000000 > > a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba > > s2 : 0000000000000000 s3 : 0000000000008902 s4 : 0000000020000300 > > s5 : ffffffe005d2b0d0 s6 : ffffffe010facfc0 s7 : ffffffe008e00000 > > s8 : 0000000000008903 s9 : ffffffe010fad080 s10: 0000000000000000 > > s11: 0000000000020000 t3 : 982de389919f6300 t4 : ffffffc401175688 > > t5 : ffffffc401175691 t6 : 0000000000000007 > > status: 0000000000000120 badaddr: 0000000020000300 cause: 000000000000000f > > Call Trace: > > [<ffffffe002aeeb3e>] sock_ioctl+0x424/0x6ac net/socket.c:1124 > > [<ffffffe0003fdb6a>] vfs_ioctl fs/ioctl.c:48 [inline] > > [<ffffffe0003fdb6a>] __do_sys_ioctl fs/ioctl.c:753 [inline] > > [<ffffffe0003fdb6a>] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739 > > [<ffffffe000005562>] ret_from_syscall+0x0/0x2 > > Dumping ftrace buffer: > > (ftrace buffer empty) > > ---[ end trace a5f91e70f37b907b ]--- > > > > > > --- > > 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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-14 10:01 ` Dmitry Vyukov @ 2021-03-14 11:03 ` Dmitry Vyukov -1 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-14 11:03 UTC (permalink / raw) To: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, Mar 10, 2021 at 7:28 PM syzbot > > <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > > > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > > > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > > > userspace arch: riscv64 > > > > > > 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+c23c5421600e9b454849@syzkaller.appspotmail.com > > > > +riscv maintainers > > > > Another case of put_user crashing. > > There are 58 crashes in sock_ioctl already. Somehow there is a very > significant skew towards crashing with this "user memory without > uaccess routines" in schedule_tail and sock_ioctl of all places in the > kernel that use put_user... This looks very strange... Any ideas > what's special about these 2 locations? I could imagine if such a crash happens after a previous stack overflow and now task data structures are corrupted. But f_getown does not look like a function that consumes way more than other kernel syscalls... > > > Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000020000300 > > > Oops [#1] > > > Modules linked in: > > > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 > > > Hardware name: riscv-virtio,qemu (DT) > > > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > > ra : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > > epc : ffffffe002aeeb3e ra : ffffffe002aeeb3e sp : ffffffe023867da0 > > > gp : ffffffe005d25378 tp : ffffffe007e116c0 t0 : 0000000000000000 > > > t1 : 0000000000000001 t2 : 0000003fb8035e44 s0 : ffffffe023867e30 > > > s1 : 0000000000040000 a0 : 0000000000000000 a1 : 0000000000000007 > > > a2 : 1ffffffc00fc22d8 a3 : ffffffe003bc1d02 a4 : 0000000000000000 > > > a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba > > > s2 : 0000000000000000 s3 : 0000000000008902 s4 : 0000000020000300 > > > s5 : ffffffe005d2b0d0 s6 : ffffffe010facfc0 s7 : ffffffe008e00000 > > > s8 : 0000000000008903 s9 : ffffffe010fad080 s10: 0000000000000000 > > > s11: 0000000000020000 t3 : 982de389919f6300 t4 : ffffffc401175688 > > > t5 : ffffffc401175691 t6 : 0000000000000007 > > > status: 0000000000000120 badaddr: 0000000020000300 cause: 000000000000000f > > > Call Trace: > > > [<ffffffe002aeeb3e>] sock_ioctl+0x424/0x6ac net/socket.c:1124 > > > [<ffffffe0003fdb6a>] vfs_ioctl fs/ioctl.c:48 [inline] > > > [<ffffffe0003fdb6a>] __do_sys_ioctl fs/ioctl.c:753 [inline] > > > [<ffffffe0003fdb6a>] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739 > > > [<ffffffe000005562>] ret_from_syscall+0x0/0x2 > > > Dumping ftrace buffer: > > > (ftrace buffer empty) > > > ---[ end trace a5f91e70f37b907b ]--- > > > > > > > > > --- > > > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-14 11:03 ` Dmitry Vyukov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-14 11:03 UTC (permalink / raw) To: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, Mar 10, 2021 at 7:28 PM syzbot > > <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > > > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > > > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > > > userspace arch: riscv64 > > > > > > 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+c23c5421600e9b454849@syzkaller.appspotmail.com > > > > +riscv maintainers > > > > Another case of put_user crashing. > > There are 58 crashes in sock_ioctl already. Somehow there is a very > significant skew towards crashing with this "user memory without > uaccess routines" in schedule_tail and sock_ioctl of all places in the > kernel that use put_user... This looks very strange... Any ideas > what's special about these 2 locations? I could imagine if such a crash happens after a previous stack overflow and now task data structures are corrupted. But f_getown does not look like a function that consumes way more than other kernel syscalls... > > > Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000020000300 > > > Oops [#1] > > > Modules linked in: > > > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 > > > Hardware name: riscv-virtio,qemu (DT) > > > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > > ra : sock_ioctl+0x424/0x6ac net/socket.c:1124 > > > epc : ffffffe002aeeb3e ra : ffffffe002aeeb3e sp : ffffffe023867da0 > > > gp : ffffffe005d25378 tp : ffffffe007e116c0 t0 : 0000000000000000 > > > t1 : 0000000000000001 t2 : 0000003fb8035e44 s0 : ffffffe023867e30 > > > s1 : 0000000000040000 a0 : 0000000000000000 a1 : 0000000000000007 > > > a2 : 1ffffffc00fc22d8 a3 : ffffffe003bc1d02 a4 : 0000000000000000 > > > a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba > > > s2 : 0000000000000000 s3 : 0000000000008902 s4 : 0000000020000300 > > > s5 : ffffffe005d2b0d0 s6 : ffffffe010facfc0 s7 : ffffffe008e00000 > > > s8 : 0000000000008903 s9 : ffffffe010fad080 s10: 0000000000000000 > > > s11: 0000000000020000 t3 : 982de389919f6300 t4 : ffffffc401175688 > > > t5 : ffffffc401175691 t6 : 0000000000000007 > > > status: 0000000000000120 badaddr: 0000000020000300 cause: 000000000000000f > > > Call Trace: > > > [<ffffffe002aeeb3e>] sock_ioctl+0x424/0x6ac net/socket.c:1124 > > > [<ffffffe0003fdb6a>] vfs_ioctl fs/ioctl.c:48 [inline] > > > [<ffffffe0003fdb6a>] __do_sys_ioctl fs/ioctl.c:753 [inline] > > > [<ffffffe0003fdb6a>] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739 > > > [<ffffffe000005562>] ret_from_syscall+0x0/0x2 > > > Dumping ftrace buffer: > > > (ftrace buffer empty) > > > ---[ end trace a5f91e70f37b907b ]--- > > > > > > > > > --- > > > 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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-14 11:03 ` Dmitry Vyukov @ 2021-03-15 11:30 ` Ben Dooks -1 siblings, 0 replies; 19+ messages in thread From: Ben Dooks @ 2021-03-15 11:30 UTC (permalink / raw) To: Dmitry Vyukov, syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On 14/03/2021 11:03, Dmitry Vyukov wrote: > On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: >>> On Wed, Mar 10, 2021 at 7:28 PM syzbot >>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: >>>> >>>> Hello, >>>> >>>> syzbot found the following issue on: >>>> >>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. >>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 >>>> userspace arch: riscv64 >>>> >>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com >>> >>> +riscv maintainers >>> >>> Another case of put_user crashing. >> >> There are 58 crashes in sock_ioctl already. Somehow there is a very >> significant skew towards crashing with this "user memory without >> uaccess routines" in schedule_tail and sock_ioctl of all places in the >> kernel that use put_user... This looks very strange... Any ideas >> what's special about these 2 locations? > > I could imagine if such a crash happens after a previous stack > overflow and now task data structures are corrupted. But f_getown does > not look like a function that consumes way more than other kernel > syscalls... The last crash I looked at suggested somehow put_user got re-entered with the user protection turned back on. Either there is a path through one of the kernel handlers where this happens or there's something weird going on with qemu. I'll be trying to get this run up on real hardware this week, the nvme with my debian install died last week so I have to go and re-install the machine to get development work done on it. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-15 11:30 ` Ben Dooks 0 siblings, 0 replies; 19+ messages in thread From: Ben Dooks @ 2021-03-15 11:30 UTC (permalink / raw) To: Dmitry Vyukov, syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv Cc: andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On 14/03/2021 11:03, Dmitry Vyukov wrote: > On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: >>> On Wed, Mar 10, 2021 at 7:28 PM syzbot >>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: >>>> >>>> Hello, >>>> >>>> syzbot found the following issue on: >>>> >>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. >>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 >>>> userspace arch: riscv64 >>>> >>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com >>> >>> +riscv maintainers >>> >>> Another case of put_user crashing. >> >> There are 58 crashes in sock_ioctl already. Somehow there is a very >> significant skew towards crashing with this "user memory without >> uaccess routines" in schedule_tail and sock_ioctl of all places in the >> kernel that use put_user... This looks very strange... Any ideas >> what's special about these 2 locations? > > I could imagine if such a crash happens after a previous stack > overflow and now task data structures are corrupted. But f_getown does > not look like a function that consumes way more than other kernel > syscalls... The last crash I looked at suggested somehow put_user got re-entered with the user protection turned back on. Either there is a path through one of the kernel handlers where this happens or there's something weird going on with qemu. I'll be trying to get this run up on real hardware this week, the nvme with my debian install died last week so I have to go and re-install the machine to get development work done on it. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-15 11:30 ` Ben Dooks @ 2021-03-15 11:52 ` Dmitry Vyukov -1 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-15 11:52 UTC (permalink / raw) To: Ben Dooks Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > On 14/03/2021 11:03, Dmitry Vyukov wrote: > > On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > >>> On Wed, Mar 10, 2021 at 7:28 PM syzbot > >>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > >>>> > >>>> Hello, > >>>> > >>>> syzbot found the following issue on: > >>>> > >>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > >>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > >>>> userspace arch: riscv64 > >>>> > >>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com > >>> > >>> +riscv maintainers > >>> > >>> Another case of put_user crashing. > >> > >> There are 58 crashes in sock_ioctl already. Somehow there is a very > >> significant skew towards crashing with this "user memory without > >> uaccess routines" in schedule_tail and sock_ioctl of all places in the > >> kernel that use put_user... This looks very strange... Any ideas > >> what's special about these 2 locations? > > > > I could imagine if such a crash happens after a previous stack > > overflow and now task data structures are corrupted. But f_getown does > > not look like a function that consumes way more than other kernel > > syscalls... > > The last crash I looked at suggested somehow put_user got re-entered > with the user protection turned back on. Either there is a path through > one of the kernel handlers where this happens or there's something > weird going on with qemu. Is there any kind of tracking/reporting that would help to localize it? I could re-reproduce with that code. > I'll be trying to get this run up on real hardware this week, the nvme > with my debian install died last week so I have to go and re-install > the machine to get development work done on it. > > -- > Ben Dooks http://www.codethink.co.uk/ > Senior Engineer Codethink - Providing Genius > > https://www.codethink.co.uk/privacy.html > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/ed89390a-91e1-320a-fae5-27b7f3a20424%40codethink.co.uk. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-15 11:52 ` Dmitry Vyukov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-15 11:52 UTC (permalink / raw) To: Ben Dooks Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > On 14/03/2021 11:03, Dmitry Vyukov wrote: > > On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > >>> On Wed, Mar 10, 2021 at 7:28 PM syzbot > >>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > >>>> > >>>> Hello, > >>>> > >>>> syzbot found the following issue on: > >>>> > >>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > >>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > >>>> userspace arch: riscv64 > >>>> > >>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com > >>> > >>> +riscv maintainers > >>> > >>> Another case of put_user crashing. > >> > >> There are 58 crashes in sock_ioctl already. Somehow there is a very > >> significant skew towards crashing with this "user memory without > >> uaccess routines" in schedule_tail and sock_ioctl of all places in the > >> kernel that use put_user... This looks very strange... Any ideas > >> what's special about these 2 locations? > > > > I could imagine if such a crash happens after a previous stack > > overflow and now task data structures are corrupted. But f_getown does > > not look like a function that consumes way more than other kernel > > syscalls... > > The last crash I looked at suggested somehow put_user got re-entered > with the user protection turned back on. Either there is a path through > one of the kernel handlers where this happens or there's something > weird going on with qemu. Is there any kind of tracking/reporting that would help to localize it? I could re-reproduce with that code. > I'll be trying to get this run up on real hardware this week, the nvme > with my debian install died last week so I have to go and re-install > the machine to get development work done on it. > > -- > Ben Dooks http://www.codethink.co.uk/ > Senior Engineer Codethink - Providing Genius > > https://www.codethink.co.uk/privacy.html > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/ed89390a-91e1-320a-fae5-27b7f3a20424%40codethink.co.uk. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-15 11:52 ` Dmitry Vyukov @ 2021-03-15 14:41 ` Ben Dooks -1 siblings, 0 replies; 19+ messages in thread From: Ben Dooks @ 2021-03-15 14:41 UTC (permalink / raw) To: Dmitry Vyukov Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On 15/03/2021 11:52, Dmitry Vyukov wrote: > On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: >> >> On 14/03/2021 11:03, Dmitry Vyukov wrote: >>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: >>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot >>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> syzbot found the following issue on: >>>>>> >>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. >>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes >>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 >>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 >>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 >>>>>> userspace arch: riscv64 >>>>>> >>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com >>>>> >>>>> +riscv maintainers >>>>> >>>>> Another case of put_user crashing. >>>> >>>> There are 58 crashes in sock_ioctl already. Somehow there is a very >>>> significant skew towards crashing with this "user memory without >>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the >>>> kernel that use put_user... This looks very strange... Any ideas >>>> what's special about these 2 locations? >>> >>> I could imagine if such a crash happens after a previous stack >>> overflow and now task data structures are corrupted. But f_getown does >>> not look like a function that consumes way more than other kernel >>> syscalls... >> >> The last crash I looked at suggested somehow put_user got re-entered >> with the user protection turned back on. Either there is a path through >> one of the kernel handlers where this happens or there's something >> weird going on with qemu. > > Is there any kind of tracking/reporting that would help to localize > it? I could re-reproduce with that code. I'm not sure. I will have a go at debugging on qemu today just to make sure I can reproduce here before I have to go into the office and fix my Icicle board for real hardware tests. I think my first plan post reproduction is to stuff some trace points into the fault handlers to see if we can get a idea of faults being processed, etc. Maybe also add a check in the fault handler to see if the fault was in a fixable region and post an error if that happens / maybe retry the instruction with the relevant SR_SUM flag set. Hopefully tomorrow I can get a run on real hardware to confirm. Would have been better if the Unmatched board I ordered last year would turn up. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-15 14:41 ` Ben Dooks 0 siblings, 0 replies; 19+ messages in thread From: Ben Dooks @ 2021-03-15 14:41 UTC (permalink / raw) To: Dmitry Vyukov Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On 15/03/2021 11:52, Dmitry Vyukov wrote: > On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: >> >> On 14/03/2021 11:03, Dmitry Vyukov wrote: >>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: >>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot >>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> syzbot found the following issue on: >>>>>> >>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. >>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes >>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 >>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 >>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 >>>>>> userspace arch: riscv64 >>>>>> >>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com >>>>> >>>>> +riscv maintainers >>>>> >>>>> Another case of put_user crashing. >>>> >>>> There are 58 crashes in sock_ioctl already. Somehow there is a very >>>> significant skew towards crashing with this "user memory without >>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the >>>> kernel that use put_user... This looks very strange... Any ideas >>>> what's special about these 2 locations? >>> >>> I could imagine if such a crash happens after a previous stack >>> overflow and now task data structures are corrupted. But f_getown does >>> not look like a function that consumes way more than other kernel >>> syscalls... >> >> The last crash I looked at suggested somehow put_user got re-entered >> with the user protection turned back on. Either there is a path through >> one of the kernel handlers where this happens or there's something >> weird going on with qemu. > > Is there any kind of tracking/reporting that would help to localize > it? I could re-reproduce with that code. I'm not sure. I will have a go at debugging on qemu today just to make sure I can reproduce here before I have to go into the office and fix my Icicle board for real hardware tests. I think my first plan post reproduction is to stuff some trace points into the fault handlers to see if we can get a idea of faults being processed, etc. Maybe also add a check in the fault handler to see if the fault was in a fixable region and post an error if that happens / maybe retry the instruction with the relevant SR_SUM flag set. Hopefully tomorrow I can get a run on real hardware to confirm. Would have been better if the Unmatched board I ordered last year would turn up. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-15 14:41 ` Ben Dooks @ 2021-03-18 15:18 ` Dmitry Vyukov -1 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-18 15:18 UTC (permalink / raw) To: Ben Dooks Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > On 15/03/2021 11:52, Dmitry Vyukov wrote: > > On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > >> > >> On 14/03/2021 11:03, Dmitry Vyukov wrote: > >>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > >>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot > >>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> syzbot found the following issue on: > >>>>>> > >>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > >>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > >>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > >>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > >>>>>> userspace arch: riscv64 > >>>>>> > >>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com > >>>>> > >>>>> +riscv maintainers > >>>>> > >>>>> Another case of put_user crashing. > >>>> > >>>> There are 58 crashes in sock_ioctl already. Somehow there is a very > >>>> significant skew towards crashing with this "user memory without > >>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the > >>>> kernel that use put_user... This looks very strange... Any ideas > >>>> what's special about these 2 locations? > >>> > >>> I could imagine if such a crash happens after a previous stack > >>> overflow and now task data structures are corrupted. But f_getown does > >>> not look like a function that consumes way more than other kernel > >>> syscalls... > >> > >> The last crash I looked at suggested somehow put_user got re-entered > >> with the user protection turned back on. Either there is a path through > >> one of the kernel handlers where this happens or there's something > >> weird going on with qemu. > > > > Is there any kind of tracking/reporting that would help to localize > > it? I could re-reproduce with that code. > > I'm not sure. I will have a go at debugging on qemu today just to make > sure I can reproduce here before I have to go into the office and fix > my Icicle board for real hardware tests. > > I think my first plan post reproduction is to stuff some trace points > into the fault handlers to see if we can get a idea of faults being > processed, etc. > > Maybe also add a check in the fault handler to see if the fault was > in a fixable region and post an error if that happens / maybe retry > the instruction with the relevant SR_SUM flag set. > > Hopefully tomorrow I can get a run on real hardware to confirm. > Would have been better if the Unmatched board I ordered last year > would turn up. In retrospect it's obvious what's common between these 2 locations: they both call a function inside of put_user. #syz dup: BUG: unable to handle kernel access to user memory in schedule_tail ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-18 15:18 ` Dmitry Vyukov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-18 15:18 UTC (permalink / raw) To: Ben Dooks Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > On 15/03/2021 11:52, Dmitry Vyukov wrote: > > On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > >> > >> On 14/03/2021 11:03, Dmitry Vyukov wrote: > >>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > >>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot > >>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> syzbot found the following issue on: > >>>>>> > >>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > >>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > >>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > >>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > >>>>>> userspace arch: riscv64 > >>>>>> > >>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com > >>>>> > >>>>> +riscv maintainers > >>>>> > >>>>> Another case of put_user crashing. > >>>> > >>>> There are 58 crashes in sock_ioctl already. Somehow there is a very > >>>> significant skew towards crashing with this "user memory without > >>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the > >>>> kernel that use put_user... This looks very strange... Any ideas > >>>> what's special about these 2 locations? > >>> > >>> I could imagine if such a crash happens after a previous stack > >>> overflow and now task data structures are corrupted. But f_getown does > >>> not look like a function that consumes way more than other kernel > >>> syscalls... > >> > >> The last crash I looked at suggested somehow put_user got re-entered > >> with the user protection turned back on. Either there is a path through > >> one of the kernel handlers where this happens or there's something > >> weird going on with qemu. > > > > Is there any kind of tracking/reporting that would help to localize > > it? I could re-reproduce with that code. > > I'm not sure. I will have a go at debugging on qemu today just to make > sure I can reproduce here before I have to go into the office and fix > my Icicle board for real hardware tests. > > I think my first plan post reproduction is to stuff some trace points > into the fault handlers to see if we can get a idea of faults being > processed, etc. > > Maybe also add a check in the fault handler to see if the fault was > in a fixable region and post an error if that happens / maybe retry > the instruction with the relevant SR_SUM flag set. > > Hopefully tomorrow I can get a run on real hardware to confirm. > Would have been better if the Unmatched board I ordered last year > would turn up. In retrospect it's obvious what's common between these 2 locations: they both call a function inside of put_user. #syz dup: BUG: unable to handle kernel access to user memory in schedule_tail _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-18 15:18 ` Dmitry Vyukov @ 2021-03-18 15:34 ` Ben Dooks -1 siblings, 0 replies; 19+ messages in thread From: Ben Dooks @ 2021-03-18 15:34 UTC (permalink / raw) To: Dmitry Vyukov Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On 18/03/2021 15:18, Dmitry Vyukov wrote: > On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: >> >> On 15/03/2021 11:52, Dmitry Vyukov wrote: >>> On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: >>>> >>>> On 14/03/2021 11:03, Dmitry Vyukov wrote: >>>>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: >>>>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot >>>>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> syzbot found the following issue on: >>>>>>>> >>>>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. >>>>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes >>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 >>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 >>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 >>>>>>>> userspace arch: riscv64 >>>>>>>> >>>>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com >>>>>>> >>>>>>> +riscv maintainers >>>>>>> >>>>>>> Another case of put_user crashing. >>>>>> >>>>>> There are 58 crashes in sock_ioctl already. Somehow there is a very >>>>>> significant skew towards crashing with this "user memory without >>>>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the >>>>>> kernel that use put_user... This looks very strange... Any ideas >>>>>> what's special about these 2 locations? >>>>> >>>>> I could imagine if such a crash happens after a previous stack >>>>> overflow and now task data structures are corrupted. But f_getown does >>>>> not look like a function that consumes way more than other kernel >>>>> syscalls... >>>> >>>> The last crash I looked at suggested somehow put_user got re-entered >>>> with the user protection turned back on. Either there is a path through >>>> one of the kernel handlers where this happens or there's something >>>> weird going on with qemu. >>> >>> Is there any kind of tracking/reporting that would help to localize >>> it? I could re-reproduce with that code. >> >> I'm not sure. I will have a go at debugging on qemu today just to make >> sure I can reproduce here before I have to go into the office and fix >> my Icicle board for real hardware tests. >> >> I think my first plan post reproduction is to stuff some trace points >> into the fault handlers to see if we can get a idea of faults being >> processed, etc. >> >> Maybe also add a check in the fault handler to see if the fault was >> in a fixable region and post an error if that happens / maybe retry >> the instruction with the relevant SR_SUM flag set. >> >> Hopefully tomorrow I can get a run on real hardware to confirm. >> Would have been better if the Unmatched board I ordered last year >> would turn up. > > In retrospect it's obvious what's common between these 2 locations: > they both call a function inside of put_user. > > #syz dup: > BUG: unable to handle kernel access to user memory in schedule_tail I think so. I've posted a patch that you can test, which should force the flags to be saved over switch_to(). I think the sanitisers are just making it easier to see. There is a seperate issue of passing complicated things to put_user() as for security, the function may be executed with the user-space protections turned off. I plan to raise this on the kernel list later once I've done some more testing. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-18 15:34 ` Ben Dooks 0 siblings, 0 replies; 19+ messages in thread From: Ben Dooks @ 2021-03-18 15:34 UTC (permalink / raw) To: Dmitry Vyukov Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On 18/03/2021 15:18, Dmitry Vyukov wrote: > On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: >> >> On 15/03/2021 11:52, Dmitry Vyukov wrote: >>> On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: >>>> >>>> On 14/03/2021 11:03, Dmitry Vyukov wrote: >>>>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: >>>>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot >>>>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> syzbot found the following issue on: >>>>>>>> >>>>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. >>>>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes >>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 >>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 >>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 >>>>>>>> userspace arch: riscv64 >>>>>>>> >>>>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com >>>>>>> >>>>>>> +riscv maintainers >>>>>>> >>>>>>> Another case of put_user crashing. >>>>>> >>>>>> There are 58 crashes in sock_ioctl already. Somehow there is a very >>>>>> significant skew towards crashing with this "user memory without >>>>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the >>>>>> kernel that use put_user... This looks very strange... Any ideas >>>>>> what's special about these 2 locations? >>>>> >>>>> I could imagine if such a crash happens after a previous stack >>>>> overflow and now task data structures are corrupted. But f_getown does >>>>> not look like a function that consumes way more than other kernel >>>>> syscalls... >>>> >>>> The last crash I looked at suggested somehow put_user got re-entered >>>> with the user protection turned back on. Either there is a path through >>>> one of the kernel handlers where this happens or there's something >>>> weird going on with qemu. >>> >>> Is there any kind of tracking/reporting that would help to localize >>> it? I could re-reproduce with that code. >> >> I'm not sure. I will have a go at debugging on qemu today just to make >> sure I can reproduce here before I have to go into the office and fix >> my Icicle board for real hardware tests. >> >> I think my first plan post reproduction is to stuff some trace points >> into the fault handlers to see if we can get a idea of faults being >> processed, etc. >> >> Maybe also add a check in the fault handler to see if the fault was >> in a fixable region and post an error if that happens / maybe retry >> the instruction with the relevant SR_SUM flag set. >> >> Hopefully tomorrow I can get a run on real hardware to confirm. >> Would have been better if the Unmatched board I ordered last year >> would turn up. > > In retrospect it's obvious what's common between these 2 locations: > they both call a function inside of put_user. > > #syz dup: > BUG: unable to handle kernel access to user memory in schedule_tail I think so. I've posted a patch that you can test, which should force the flags to be saved over switch_to(). I think the sanitisers are just making it easier to see. There is a seperate issue of passing complicated things to put_user() as for security, the function may be executed with the user-space protections turned off. I plan to raise this on the kernel list later once I've done some more testing. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl 2021-03-18 15:34 ` Ben Dooks @ 2021-03-18 15:54 ` Dmitry Vyukov -1 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-18 15:54 UTC (permalink / raw) To: Ben Dooks Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Thu, Mar 18, 2021 at 4:35 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > On 18/03/2021 15:18, Dmitry Vyukov wrote: > > On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > >> > >> On 15/03/2021 11:52, Dmitry Vyukov wrote: > >>> On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > >>>> > >>>> On 14/03/2021 11:03, Dmitry Vyukov wrote: > >>>>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > >>>>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot > >>>>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > >>>>>>>> > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> syzbot found the following issue on: > >>>>>>>> > >>>>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > >>>>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > >>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > >>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > >>>>>>>> userspace arch: riscv64 > >>>>>>>> > >>>>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com > >>>>>>> > >>>>>>> +riscv maintainers > >>>>>>> > >>>>>>> Another case of put_user crashing. > >>>>>> > >>>>>> There are 58 crashes in sock_ioctl already. Somehow there is a very > >>>>>> significant skew towards crashing with this "user memory without > >>>>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the > >>>>>> kernel that use put_user... This looks very strange... Any ideas > >>>>>> what's special about these 2 locations? > >>>>> > >>>>> I could imagine if such a crash happens after a previous stack > >>>>> overflow and now task data structures are corrupted. But f_getown does > >>>>> not look like a function that consumes way more than other kernel > >>>>> syscalls... > >>>> > >>>> The last crash I looked at suggested somehow put_user got re-entered > >>>> with the user protection turned back on. Either there is a path through > >>>> one of the kernel handlers where this happens or there's something > >>>> weird going on with qemu. > >>> > >>> Is there any kind of tracking/reporting that would help to localize > >>> it? I could re-reproduce with that code. > >> > >> I'm not sure. I will have a go at debugging on qemu today just to make > >> sure I can reproduce here before I have to go into the office and fix > >> my Icicle board for real hardware tests. > >> > >> I think my first plan post reproduction is to stuff some trace points > >> into the fault handlers to see if we can get a idea of faults being > >> processed, etc. > >> > >> Maybe also add a check in the fault handler to see if the fault was > >> in a fixable region and post an error if that happens / maybe retry > >> the instruction with the relevant SR_SUM flag set. > >> > >> Hopefully tomorrow I can get a run on real hardware to confirm. > >> Would have been better if the Unmatched board I ordered last year > >> would turn up. > > > > In retrospect it's obvious what's common between these 2 locations: > > they both call a function inside of put_user. > > > > #syz dup: > > BUG: unable to handle kernel access to user memory in schedule_tail > > I think so. I've posted a patch that you can test, which should force > the flags to be saved over switch_to(). I think the sanitisers are just > making it easier to see. > > There is a seperate issue of passing complicated things to put_user() > as for security, the function may be executed with the user-space > protections turned off. I plan to raise this on the kernel list later > once I've done some more testing. Thanks for quick debugging and the fix. This is the top crasher on the syzbot instance, so this will unblock real testing. I think I will trust your testing. syzbot instance is now on riscv/fixes branch, so it will pick it up as soon as it's in that tree (hopefully soon) and will do as exhaustive testing as possible :) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl @ 2021-03-18 15:54 ` Dmitry Vyukov 0 siblings, 0 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-18 15:54 UTC (permalink / raw) To: Ben Dooks Cc: syzbot, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv, andrii, Alexei Starovoitov, bpf, Daniel Borkmann, David Miller, John Fastabend, Martin KaFai Lau, kpsingh, Jakub Kicinski, LKML, netdev, Song Liu, syzkaller-bugs, Yonghong Song On Thu, Mar 18, 2021 at 4:35 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > > On 18/03/2021 15:18, Dmitry Vyukov wrote: > > On Mon, Mar 15, 2021 at 3:41 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > >> > >> On 15/03/2021 11:52, Dmitry Vyukov wrote: > >>> On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote: > >>>> > >>>> On 14/03/2021 11:03, Dmitry Vyukov wrote: > >>>>> On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@google.com> wrote: > >>>>>>> On Wed, Mar 10, 2021 at 7:28 PM syzbot > >>>>>>> <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com> wrote: > >>>>>>>> > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> syzbot found the following issue on: > >>>>>>>> > >>>>>>>> HEAD commit: 0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. > >>>>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes > >>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad00000 > >>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136 > >>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849 > >>>>>>>> userspace arch: riscv64 > >>>>>>>> > >>>>>>>> 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+c23c5421600e9b454849@syzkaller.appspotmail.com > >>>>>>> > >>>>>>> +riscv maintainers > >>>>>>> > >>>>>>> Another case of put_user crashing. > >>>>>> > >>>>>> There are 58 crashes in sock_ioctl already. Somehow there is a very > >>>>>> significant skew towards crashing with this "user memory without > >>>>>> uaccess routines" in schedule_tail and sock_ioctl of all places in the > >>>>>> kernel that use put_user... This looks very strange... Any ideas > >>>>>> what's special about these 2 locations? > >>>>> > >>>>> I could imagine if such a crash happens after a previous stack > >>>>> overflow and now task data structures are corrupted. But f_getown does > >>>>> not look like a function that consumes way more than other kernel > >>>>> syscalls... > >>>> > >>>> The last crash I looked at suggested somehow put_user got re-entered > >>>> with the user protection turned back on. Either there is a path through > >>>> one of the kernel handlers where this happens or there's something > >>>> weird going on with qemu. > >>> > >>> Is there any kind of tracking/reporting that would help to localize > >>> it? I could re-reproduce with that code. > >> > >> I'm not sure. I will have a go at debugging on qemu today just to make > >> sure I can reproduce here before I have to go into the office and fix > >> my Icicle board for real hardware tests. > >> > >> I think my first plan post reproduction is to stuff some trace points > >> into the fault handlers to see if we can get a idea of faults being > >> processed, etc. > >> > >> Maybe also add a check in the fault handler to see if the fault was > >> in a fixable region and post an error if that happens / maybe retry > >> the instruction with the relevant SR_SUM flag set. > >> > >> Hopefully tomorrow I can get a run on real hardware to confirm. > >> Would have been better if the Unmatched board I ordered last year > >> would turn up. > > > > In retrospect it's obvious what's common between these 2 locations: > > they both call a function inside of put_user. > > > > #syz dup: > > BUG: unable to handle kernel access to user memory in schedule_tail > > I think so. I've posted a patch that you can test, which should force > the flags to be saved over switch_to(). I think the sanitisers are just > making it easier to see. > > There is a seperate issue of passing complicated things to put_user() > as for security, the function may be executed with the user-space > protections turned off. I plan to raise this on the kernel list later > once I've done some more testing. Thanks for quick debugging and the fix. This is the top crasher on the syzbot instance, so this will unblock real testing. I think I will trust your testing. syzbot instance is now on riscv/fixes branch, so it will pick it up as soon as it's in that tree (hopefully soon) and will do as exhaustive testing as possible :) _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-03-18 15:55 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-10 18:28 [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl syzbot 2021-03-10 18:53 ` Dmitry Vyukov 2021-03-10 18:53 ` Dmitry Vyukov 2021-03-14 10:01 ` Dmitry Vyukov 2021-03-14 10:01 ` Dmitry Vyukov 2021-03-14 11:03 ` Dmitry Vyukov 2021-03-14 11:03 ` Dmitry Vyukov 2021-03-15 11:30 ` Ben Dooks 2021-03-15 11:30 ` Ben Dooks 2021-03-15 11:52 ` Dmitry Vyukov 2021-03-15 11:52 ` Dmitry Vyukov 2021-03-15 14:41 ` Ben Dooks 2021-03-15 14:41 ` Ben Dooks 2021-03-18 15:18 ` Dmitry Vyukov 2021-03-18 15:18 ` Dmitry Vyukov 2021-03-18 15:34 ` Ben Dooks 2021-03-18 15:34 ` Ben Dooks 2021-03-18 15:54 ` Dmitry Vyukov 2021-03-18 15:54 ` Dmitry Vyukov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.