linux-kernel - Re: [PATCH-next v2 2/2] scsi: fix iscsi rescan fails to create block device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y9YWMQ4TuJfuXAzL@kroah.com>
Date:   Sun, 29 Jan 2023 07:46:09 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Yu Kuai <yukuai1@...weicloud.com>
Cc:     Zhong Jinghua <zhongjinghua@...wei.com>, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, hare@...e.de, bvanassche@....org,
        emilne@...hat.com, linux-kernel@...r.kernel.org,
        linux-scsi@...r.kernel.org, yi.zhang@...wei.com,
        "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH-next v2 2/2] scsi: fix iscsi rescan fails to create block
 device

On Sun, Jan 29, 2023 at 09:13:55AM +0800, Yu Kuai wrote:
> Hi, Greg
> 
> 在 2023/01/28 18:45, Greg KH 写道:
> > > diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> > > index cac7c902cf70..a22109cdb8ef 100644
> > > --- a/drivers/scsi/scsi_sysfs.c
> > > +++ b/drivers/scsi/scsi_sysfs.c
> > > @@ -1535,9 +1535,7 @@ static void __scsi_remove_target(struct scsi_target *starget)
> > >   		if (sdev->channel != starget->channel ||
> > >   		    sdev->id != starget->id)
> > >   			continue;
> > > -		if (sdev->sdev_state == SDEV_DEL ||
> > > -		    sdev->sdev_state == SDEV_CANCEL ||
> > > -		    !get_device(&sdev->sdev_gendev))
> > > +		if (!get_device_unless_zero(&sdev->sdev_gendev))
> > 
> > If sdev_gendev is 0 here, the object is gone and you are working with
> > memory that is already freed so something is _VERY_ wrong.
> 
> In fact, this patch will work:
> 
> In __scsi_remove_target(), 'host_lock' is held to protect iterating
> siblings, and object will wait for this lock in
> scsi_device_dev_release() to remove siblings. Hence sdev will not be
> freed untill the lock is released.

Then you got lucky, as that is not how a reference counted object should
be working (i.e. the reference dropped to 0 and it still be kept alive.)

Please fix up the scsi logic here, don't abuse the reference count code.

thanks,

greg k-h