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