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

Ben Dooks ben.dooks at codethink.co.uk
Mon Mar 15 11:30:28 GMT 2021


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



More information about the linux-riscv mailing list