Re: linux kernel security issuse scsi_report_lun_scan report

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2015-11-20 at 12:54 -0800, Linus Torvalds wrote:
> On Fri, Nov 20, 2015 at 10:26 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > We can look at it, but the analysis shouldn't be correct.  This device
> > is the one we first used to issue the report lun scan.  Either it's an
> > existing device, or we created it specially for the purpose.  If it's an
> > existing one, that put just releases our reference, but the core still
> > has one  (there'd have to be a very unusual scan destroy race for the
> > core to be releasing a reference to an object it was in process of
> > scanning).
> 
> Side note: that whole "if it's an existing one" looks fundamentally racy.
> 
> What if two threads have that existing one, and both threads decide
> "there's no device there", so they'll both decide to do that
> __scsi_remove_device()?

It's done under the scan mutex, so there can only be one thread in that
code at once.

James


> In fact, one of the threads might have created the device, so it looks
> like it's sufficient that just one thread has that
> "scsi_device_lookup_by_target()" case..
> 
> I don't see any serialization around this.
> 
> Now, I do agree that it's odd that this happens during early kernel
> initcalls, but the scsi layer is one of the things that uses async
> stuff, so if that do_scan_async() ever ends up using the same target
> twice, that would explain it. Can that happen some way?
> 
>              Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>