All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: syzbot <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv <linux-riscv@lists.infradead.org>
Cc: andrii@kernel.org, Alexei Starovoitov <ast@kernel.org>,
	bpf <bpf@vger.kernel.org>, Daniel Borkmann <daniel@iogearbox.net>,
	David Miller <davem@davemloft.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Martin KaFai Lau <kafai@fb.com>,
	kpsingh@kernel.org, Jakub Kicinski <kuba@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>, Song Liu <songliubraving@fb.com>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Yonghong Song <yhs@fb.com>
Subject: Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl
Date: Sun, 14 Mar 2021 11:01:39 +0100	[thread overview]
Message-ID: <CACT4Y+ZjVS+nOxtEByF5-djuhbCYLSDdZ7V04qJ0edpQR0514A@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+ZjdOaX_X530p+vPbG4mbtUuFsJ1v-gD24T4DnFUqcudA@mail.gmail.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Vyukov <dvyukov@google.com>
To: syzbot <syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com>,
	 Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv <linux-riscv@lists.infradead.org>
Cc: andrii@kernel.org, Alexei Starovoitov <ast@kernel.org>,
	bpf <bpf@vger.kernel.org>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	David Miller <davem@davemloft.net>,
	 John Fastabend <john.fastabend@gmail.com>,
	Martin KaFai Lau <kafai@fb.com>,
	kpsingh@kernel.org,  Jakub Kicinski <kuba@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	 netdev <netdev@vger.kernel.org>,
	Song Liu <songliubraving@fb.com>,
	 syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Yonghong Song <yhs@fb.com>
Subject: Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl
Date: Sun, 14 Mar 2021 11:01:39 +0100	[thread overview]
Message-ID: <CACT4Y+ZjVS+nOxtEByF5-djuhbCYLSDdZ7V04qJ0edpQR0514A@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+ZjdOaX_X530p+vPbG4mbtUuFsJ1v-gD24T4DnFUqcudA@mail.gmail.com>

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

  reply	other threads:[~2021-03-14 10:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACT4Y+ZjVS+nOxtEByF5-djuhbCYLSDdZ7V04qJ0edpQR0514A@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=andrii@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=songliubraving@fb.com \
    --cc=syzbot+c23c5421600e9b454849@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.