netdev - RE: [PATCH 1/1] netvsc: Deal with rescinded channels correctly

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: <CY4PR03MB24876F43572194D377DAB713A0180@CY4PR03MB2487.namprd03.prod.outlook.com>
Date:   Wed, 19 Apr 2017 20:52:14 +0000
From:   KY Srinivasan <kys@...rosoft.com>
To:     KY Srinivasan <kys@...rosoft.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
        "olaf@...fle.de" <olaf@...fle.de>,
        "apw@...onical.com" <apw@...onical.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "leann.ogasawara@...onical.comi" <leann.ogasawara@...onical.comi>,
        "marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>
Subject: RE: [PATCH 1/1] netvsc: Deal with rescinded channels correctly



> -----Original Message-----
> From: kys@...hange.microsoft.com [mailto:kys@...hange.microsoft.com]
> Sent: Wednesday, April 19, 2017 1:49 PM
> To: davem@...emloft.net; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org; devel@...uxdriverproject.org; olaf@...fle.de;
> apw@...onical.com; jasowang@...hat.com;
> leann.ogasawara@...onical.comi; marcelo.cerri@...onical.com; Stephen
> Hemminger <sthemmin@...rosoft.com>
> Cc: KY Srinivasan <kys@...rosoft.com>
> Subject: [PATCH 1/1] netvsc: Deal with rescinded channels correctly
> 
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> 
> From: K. Y. Srinivasan <kys@...rosoft.com>
> 
> We will not be able to send packets over a channel that has been
> rescinded. Make necessary adjustments so we can properly cleanup
> even when the channel is rescinded. This issue can be trigerred
> in the NIC hot-remove path.
> 
> Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>

Dave,

Please drop this path; I will resend.

K. Y
> ---
>  drivers/net/hyperv/netvsc.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 7ab06b3..b5b10fc 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -135,6 +135,13 @@ static void netvsc_destroy_buf(struct hv_device
> *device)
>                                        sizeof(struct nvsp_message),
>                                        (unsigned long)revoke_packet,
>                                        VM_PKT_DATA_INBAND, 0);
> +               /* If the failure is because the channel is rescinded;
> +                * ignore the failure since we cannot send on a rescinded
> +                * channel. This would allow us to properly cleanup
> +                * even when the channel is rescinded.
> +                */
> +               if (device->channel->rescind)
> +                       ret = 0;
>                 /*
>                  * If we failed here, we might as well return and
>                  * have a leak rather than continue and a bugchk
> @@ -195,6 +202,15 @@ static void netvsc_destroy_buf(struct hv_device
> *device)
>                                        sizeof(struct nvsp_message),
>                                        (unsigned long)revoke_packet,
>                                        VM_PKT_DATA_INBAND, 0);
> +
> +               /* If the failure is because the channel is rescinded;
> +                * ignore the failure since we cannot send on a rescinded
> +                * channel. This would allow us to properly cleanup
> +                * even when the channel is rescinded.
> +                */
> +               if (device->channel->rescind)
> +                       ret = 0;
> +
>                 /* If we failed here, we might as well return and
>                  * have a leak rather than continue and a bugchk
>                  */
> --
> 1.7.1