On Mon, Mar 15, 2021 at 12:30 PM Ben Dooks <ben.dooks@xxxxxxxxxxxxxxx> wrote: > > On 14/03/2021 11:03, Dmitry Vyukov wrote: > > On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > >>> On Wed, Mar 10, 2021 at 7:28 PM syzbot > >>> <syzbot+c23c5421600e9b454849@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx > >>> > >>> +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@xxxxxxxxxxxxxxxx. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/ed89390a-91e1-320a-fae5-27b7f3a20424%40codethink.co.uk.
