[syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl

[syzbot]

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+c23c54...@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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[Dmitry Vyukov]

On Wed, Mar 10, 2021 at 7:28 PM syzbot
<syzbot+c23c54...@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+c23c54...@syzkaller.appspotmail.com

+riscv maintainers

Another case of put_user crashing.

> --
> 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-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000096cdaa05bd32d46f%40google.com.

[Dmitry Vyukov]

On Wed, Mar 10, 2021 at 7:53 PM Dmitry Vyukov <dvy...@google.com> wrote:
>
> On Wed, Mar 10, 2021 at 7:28 PM syzbot
> <syzbot+c23c54...@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+c23c54...@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?

[Dmitry Vyukov]

On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvy...@google.com> wrote:
> > On Wed, Mar 10, 2021 at 7:28 PM syzbot
> > <syzbot+c23c54...@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+c23c54...@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...

[Ben Dooks]

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

[Dmitry Vyukov]

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-bug...@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.

[Ben Dooks]

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.

[Dmitry Vyukov]

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

[Ben Dooks]

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.

[Dmitry Vyukov]

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