Messages in this thread | | | Subject | Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail | From | Ben Dooks <> | Date | Mon, 15 Mar 2021 16:55:27 +0000 |
| |
On 13/03/2021 07:20, Dmitry Vyukov wrote: > On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>> Still no luck for the moment, can't reproduce it locally, my test is >>> maybe not that good (I created threads all day long in order to trigger >>> the put_user of schedule_tail). >> >> It may of course depend on memory and other stuff. I did try to see if >> it was possible to clone() with the child_tid address being a valid but >> not mapped page... >> >>> Given that the path you mention works most of the time, and that the >>> status register in the stack trace shows the SUM bit is not set whereas >>> it is set in put_user, I'm leaning toward some race condition (maybe an >>> interrupt that arrives at the "wrong" time) or a qemu issue as you >>> mentioned. >> >> I suppose this is possible. From what I read it should get to the >> point of being there with the SUM flag cleared, so either something >> went wrong in trying to fix the instruction up or there's some other >> error we're missing. >> >>> To eliminate qemu issues, do you have access to some HW ? Or to >>> different qemu versions ? >> >> I do have access to a Microchip Polarfire board. I just need the >> instructions on how to setup the test-code to make it work on the >> hardware. > > For full syzkaller support, it would need to know how to reboot these > boards and get access to the console. > syzkaller has a stop-gap VM backend which just uses ssh to a physical > machine and expects the kernel to reboot on its own after any crashes. > > But I actually managed to reproduce it in an even simpler setup. > Assuming you have Go 1.15 and riscv64 cross-compiler gcc installed > > $ go get -u -d github.com/google/syzkaller/... > $ cd $GOPATH/src/github.com/google/syzkaller > $ make stress executor TARGETARCH=riscv64 > $ scp bin/linux_riscv64/syz-execprog bin/linux_riscv64/syz-executor > your_machine:/ > > Then run ./syz-stress on the machine. > On the first run it crashed it with some other bug, on the second run > I got the crash in schedule_tail. > With qemu tcg I also added -slowdown=10 flag to syz-stress to scale > all timeouts, if native execution is faster, then you don't need it.
I have built the tools and got it to start.
It would be helpful for the dashboard to give the qemu version and how it was launched (memory, cpus etc)
-- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
| |