linux-kernel - RE: [PATCH 2/2] PCI: hv: handle all pending messages in hv_pci

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]

Date:	Tue, 31 May 2016 17:36:17 +0000
From:	Jake Oshins <jakeo@...rosoft.com>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	KY Srinivasan <kys@...rosoft.com>
Subject: RE: [PATCH 2/2] PCI: hv: handle all pending messages in
 hv_pci_onchannelcallback()

> -----Original Message-----
> From: Vitaly Kuznetsov [mailto:vkuznets@...hat.com]
> Sent: Monday, May 30, 2016 7:18 AM
> To: linux-pci@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org; devel@...uxdriverproject.org; Bjorn
> Helgaas <bhelgaas@...gle.com>; Haiyang Zhang
> <haiyangz@...rosoft.com>; KY Srinivasan <kys@...rosoft.com>; Jake
> Oshins <jakeo@...rosoft.com>
> Subject: [PATCH 2/2] PCI: hv: handle all pending messages in
> hv_pci_onchannelcallback()
> 
> When we have an interrupt from host we have a bit set in event page
> indicating there are messages for the particular channel. We need to read
> them all as we won't get signaled for what was on the queue before we
> cleared the bit in vmbus_on_event(). This applies to all Hyper-V drivers
> and the pass-through driver should do the same.
> I did non meet any bugs, the issue was found by code inspection. We don't
> have many events going through hv_pci_onchannelcallback(), this explains
> why nobody reported the issue before.
> 
> While on it, fix handling non-zero vmbus_recvpacket_raw() return values by
> dropping out. If the return value is not zero it is wrong to inspect
> buffer or bytes_recvd as these may contain invalid data.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
Acked-by: Jake Oshins <jakeo@...rosoft.com>

> ---
>  drivers/pci/host/pci-hyperv.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index a68ec49..7de341d 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1657,12 +1657,16 @@ static void hv_pci_onchannelcallback(void
> *context)
>  			continue;
>  		}
> 
> +		/* Zero length indicates there are no more packets. */
> +		if (ret || !bytes_recvd)
> +			break;
> +
>  		/*
>  		 * All incoming packets must be at least as large as a
>  		 * response.
>  		 */
>  		if (bytes_recvd <= sizeof(struct pci_response))
> -			break;
> +			continue;
>  		desc = (struct vmpacket_descriptor *)buffer;
> 
>  		switch (desc->type) {
> @@ -1724,7 +1728,6 @@ static void hv_pci_onchannelcallback(void
> *context)
>  				desc->type, req_id, bytes_recvd);
>  			break;
>  		}
> -		break;
>  	}
> 
>  	kfree(buffer);
> --
> 2.5.5

This is good, too.

Thanks,
Jake Oshins