Uh, I've answered this a week ago, but did not notice that Doug
dropped everybody from CC. Reporting to all.
On Mon, Jan 22, 2018 at 8:16 PM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote:
> On 2018-01-22 02:06 PM, Dmitry Vyukov wrote:
>>
>> On Mon, Jan 22, 2018 at 7:57 PM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
> Please show me the output of 'lsscsi -g' on your test machine.
> /dev/sg0 is often associated with /dev/sda which is often a SATA
> SSD (or a virtualized one) that holds the root file system.
> With the sg pass-through driver it is relatively easy to write
> random (user provided data) over the root file system which will
> almost certainly "root" the system.
This is pretty standard qemu vm started with:
qemu-system-x86_64 -hda wheezy.img -net user,host=10.0.2.10 -net nic
-nographic -kernel arch/x86/boot/bzImage -append "console=ttyS0
root=/dev/sda earlyprintk=serial " -m 2G -smp 4
# lsscsi -g
[0:0:0:0] disk ATA QEMU HARDDISK 0 /dev/sda /dev/sg0
[1:0:0:0] cd/dvd QEMU QEMU DVD-ROM 2.0. /dev/sr0 /dev/sg1
# readlink /sys/class/scsi_generic/sg0
../../devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:0/0:0:0:0/scsi_generic/sg0
# cat /sys/class/scsi_generic/sg0/device/vendor
ATA
>>> Perhaps it misbehaves when it
>>> gets a SCSI command in the T10 range (i.e. not vendor specific) with
>>> a 9 byte cdb length. As far as I'm aware T10 (and the Ansi committee
>>> before it) have never defined a cdb with an odd length.
>>>
>>> For those that are not aware, the sg driver is a relatively thin
>>> shim over the block layer, the SCSI mid-level, and a low-level
>>> driver which may have another kernel driver stack underneath it
>>> (e.g. UAS (USB attached SCSI)). The previous report from syzkaller
>>> on the sg driver ("scsi: memory leak in sg_start_req") has resulted
>>> in one accepted patch on the block layer with probably more to
>>> come in the same area.
>>>
>>> Testing the patch Dmitry gave (with some added error checks which
>>> reported no problems) with the scsi_debug driver supplying /dev/sg0
>>> I have not seen any problems running that test program. Again
>>> there might be a very slow memory leak, but if there is I don't
>>> believe it is in the sg driver.
>>
>>
>> Did you run it in a loop? First runs pass just fine for me too.
>
>
> Is thirty minutes long enough ??
Yes, it certainly should be enough. Here is what I see:
# while ./a.out; do echo RUN; done
RUN
RUN
RUN
RUN
RUN
RUN
RUN
[ 371.977266] ==================================================================
[ 371.980158] BUG: KASAN: double-free or invalid-free in
__put_task_struct+0x1e7/0x5c0
....
Here is full execution trace of the write call if that will be of any help:
https://gist.githubusercontent.com/dvyukov/14ae64c3e753dedf9ab2608676ecf0b9/raw/9803d52bb1e317a9228e362236d042aaf0fa9d69/gistfile1.txt
This is on upstream commit 0d665e7b109d512b7cae3ccef6e8654714887844.
Also attaching my config just in case.
Attachment:
.config
Description: Binary data
