From: Andrea Parri (Microsoft) <parri.andrea@xxxxxxxxx> Sent: Tuesday, October 5, 2021 4:41 AM
>
> The validation on the length of incoming packets performed in
> storvsc_on_channel_callback() does not apply to unsolicited
> packets with ID of 0 sent by Hyper-V. Adjust the validation
> for such unsolicited packets.
>
> Fixes: 91b1b640b834b2 ("scsi: storvsc: Validate length of incoming packet in storvsc_on_channel_callback()")
> Reported-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@xxxxxxxxx>
> Reviewed-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> ---
> Changes since RFC[1]:
> - Merge length checks (Haiyang Zhang)
>
> [1] https://lore.kernel.org/all/20210928163732.5908-1-parri.andrea@xxxxxxxxx/T/#u
>
> drivers/scsi/storvsc_drv.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index ebbbc1299c625..349c1071a98d4 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -292,6 +292,9 @@ struct vmstorage_protocol_version {
> #define STORAGE_CHANNEL_REMOVABLE_FLAG 0x1
> #define STORAGE_CHANNEL_EMULATED_IDE_FLAG 0x2
>
> +/* Lower bound on the size of unsolicited packets with ID of 0 */
> +#define VSTOR_MIN_UNSOL_PKT_SIZE 48
> +
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. So an alternate approach is to set
the minimum length as small as possible while ensuring that field is valid.
Then if Hyper-V later changes the size of these unsolicited packets to
some smaller size that still contains a valid "operation" field, this code
will still work. If in a new version of the protocol Hyper-V adds fields
that this driver needs to look at, then the minimum size can be
adjusted as needed for that new protocol version.
> struct vstor_packet {
> /* Requested operation type */
> enum vstor_packet_operation operation;
> @@ -1285,11 +1288,15 @@ static void storvsc_on_channel_callback(void *context)
> foreach_vmbus_pkt(desc, channel) {
> struct vstor_packet *packet = hv_pkt_data(desc);
> struct storvsc_cmd_request *request = NULL;
> + u32 pktlen = hv_pkt_datalen(desc);
> u64 rqst_id = desc->trans_id;
> + u32 minlen = rqst_id ? sizeof(struct vstor_packet) -
> + stor_device->vmscsi_size_delta : VSTOR_MIN_UNSOL_PKT_SIZE;
>
> - if (hv_pkt_datalen(desc) < sizeof(struct vstor_packet) -
> - stor_device->vmscsi_size_delta) {
> - dev_err(&device->device, "Invalid packet len\n");
> + if (pktlen < minlen) {
> + dev_err(&device->device,
> + "Invalid pkt: id=%llu, len=%u, minlen=%u\n",
> + rqst_id, pktlen, minlen);
> continue;
> }
>
> --
> 2.25.1
I'm good with the rest of the code. It's just a question of whether to perhaps
"future-proof" the code by not requiring a packet size any bigger than the
driver actually needs to reference.
Michael
