Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 6 Oct 2021 15:39:09 +0200
From:   Andrea Parri <parri.andrea@gmail.com>
To:     Michael Kelley <mikelley@microsoft.com>
Cc:     Long Li <longli@microsoft.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        KY Srinivasan <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>,
        "James E . J . Bottomley" <jejb@linux.ibm.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>,
        Dexuan Cui <decui@microsoft.com>
Subject: Re: [PATCH] scsi: storvsc: Fix validation for unsolicited incoming
 packets
Message-ID: <20211006133909.GA22926@anparri>
References: <20211005114103.3411-1-parri.andrea@gmail.com>
 <MWHPR21MB15935C9A0C33A858AFF1A825D7AF9@MWHPR21MB1593.namprd21.prod.outlook.com>
 <20211005181421.GA1714@anparri>
 <MWHPR21MB15933E46ABC6DC0AA5DD0A5AD7AF9@MWHPR21MB1593.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MWHPR21MB15933E46ABC6DC0AA5DD0A5AD7AF9@MWHPR21MB1593.namprd21.prod.outlook.com>
Precedence: bulk

> > > I know you have determined experimentally that Hyper-V sends
> > > unsolicited packets with the above length, so the idea is to validate
> > > that the guest actually gets packets at least that big.  But I wonder if
> > > we should think about this slightly differently.
> > >
> > > The goal is for the storvsc driver to protect itself against bad or
> > > malicious messages from Hyper-V.  For the unsolicited messages, the
> > > only field that this storvsc driver needs to access is the
> > > vstor_packet->operation field.
> > 
> > Eh, this is one piece of information I was looking for...  ;-)
> 
> I'm just looking at the code in storvsc_on_receive().   storvsc_on_receive()
> itself looks at the "operation" field, but for the REMOVE_DEVICE and
> ENUMERATE_BUS operations, you can see that the rest of the vstor_packet
> is ignored and is not passed to any called functions.
> 
> > 
> > 
> > >So an alternate approach is to set
> > > the minimum length as small as possible while ensuring that field is valid.
> > 
> > The fact is, I'm not sure how to do it for unsolicited messages.
> > Current code ensures/checks != COMPLETE_IO.  Your comment above
> > and code audit suggest that we should add a check != FCHBA_DATA.
> > I saw ENUMERATE_BUS messages, code only using their "operation".
> 
> I'm not completely sure about FCHBA_DATA.  That message does not
> seem to be unsolicited, as the guest sends out a message of that type in 
> storvsc_channel_init() using storvsc_execute_vstor_op().  So any received
> messages of that type are presumably in response to the guest request,
> and will get handled via the test for rqst_id == VMBUS_RQST_INIT.  Long 
> Li could probably confirm.  So if Hyper-V did send a FCHBA_DATA
> packet with rqst_id of 0, it would seem to be appropriate to reject
> it.
> 
> > 
> > And, again, this is only based on current code/observations...
> > 
> > So, maybe you mean something like this (on top of this patch)?
> 
> Yes, with a comment to explain what's going on. :-)

My (current) best guess is here:

  https://lkml.kernel.org/r/20211006132026.4089-1-parri.andrea@gmail.com

Thanks,
  Andrea