linux-kernel - Re: [PATCH] scsi: storvsc: Fix validation for unsolicited incoming packets

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] [day] [month] [year] [list]

Message-ID: <20211006133909.GA22926@anparri>
Date:   Wed, 6 Oct 2021 15:39:09 +0200
From:   Andrea Parri <parri.andrea@...il.com>
To:     Michael Kelley <mikelley@...rosoft.com>
Cc:     Long Li <longli@...rosoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>,
        "James E . J . Bottomley" <jejb@...ux.ibm.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Dexuan Cui <decui@...rosoft.com>
Subject: Re: [PATCH] scsi: storvsc: Fix validation for unsolicited incoming
 packets

> > > 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