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

From: Ben Dooks <ben.dooks@codethink.co.uk>
To: Dmitry Vyukov <dvyukov@google.com>,
	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: Mon, 15 Mar 2021 11:30:28 +0000	[thread overview]
Message-ID: <ed89390a-91e1-320a-fae5-27b7f3a20424@codethink.co.uk> (raw)
In-Reply-To: <CACT4Y+YXifnCtEvLu3ps8JLCK9CBLzEuUAozfNR9v1hsGWspOg@mail.gmail.com>

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