On 2018-08-03 11:47 AM, gaowanlong wrote:
Doug,
On 2018-08-03 04:46 AM, Wanlong Gao wrote:
Hi Martinand all folks,
Recently we find a kernel panic with memory corruption caused by SG_IO ioctl(),
and it can be easily reproduced by running following reproducer about
minutes,any idea?
Which kernel?
We've tested with 4.17.11 and 4.18.rc7 and both reproduced.
And what are the underlying devices (e.g. does /dev/sg0 refer to a SATA disk,
a real SCSI disk (SAS for example), USB mass storage, etc)?
We tested in a qemu-kvm guest and the sg0 refer to a virtual SATA disk.
Thanks for the prompt reply.
The first test I am doing, and you can also do, is to replace the virtual
SATA disk with a scsi_debug pseudo SCSI disk(s). This will tell us
whether libata has a hand in this (as that was the case in a previous
syzkaller report on the SG_IO ioctl()).
Also can you get a copy of the kernel panic?
Since the call traces are different every time it reproduced, that I didn't paste the
call trace or the vmcore, but this reproducer is very useful and I believe you can reproduce
it easily using the following code.
Okay.
As I write I'm running your reproducer with lk 4.18.0-rc6 against pseudo
scsi_debug "disks". So far no problems (5 minutes) with no noise in syslog.