linux-kernel - Re: [PATCH net, 1/2] hv_netvsc: Fix offset usage in netvsc_send

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:   Mon, 18 Nov 2019 18:28:48 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Haiyang Zhang <haiyangz@...rosoft.com>
Cc:     KY Srinivasan <kys@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "olaf\@aepfle.de" <olaf@...fle.de>,
        "davem\@davemloft.net" <davem@...emloft.net>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "sashal\@kernel.org" <sashal@...nel.org>,
        "linux-hyperv\@vger.kernel.org" <linux-hyperv@...r.kernel.org>,
        "netdev\@vger.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net, 1/2] hv_netvsc: Fix offset usage in netvsc_send_table()

Haiyang Zhang <haiyangz@...rosoft.com> writes:

> To reach the data region, the existing code adds offset in struct
> nvsp_5_send_indirect_table on the beginning of this struct. But the
> offset should be based on the beginning of its container,
> struct nvsp_message. This bug causes the first table entry missing,
> and adds an extra zero from the zero pad after the data region.
> This can put extra burden on the channel 0.
>
> So, correct the offset usage. Also add a boundary check to ensure
> not reading beyond data region.
>
> Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
> Signed-off-by: Haiyang Zhang <haiyangz@...rosoft.com>
> ---
>  drivers/net/hyperv/hyperv_net.h |  3 ++-
>  drivers/net/hyperv/netvsc.c     | 26 ++++++++++++++++++--------
>  2 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index 670ef68..fb547f3 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@ -609,7 +609,8 @@ struct nvsp_5_send_indirect_table {
>  	/* The number of entries in the send indirection table */
>  	u32 count;
>  
> -	/* The offset of the send indirection table from top of this struct.
> +	/* The offset of the send indirection table from the beginning of
> +	 * struct nvsp_message.
>  	 * The send indirection table tells which channel to put the send
>  	 * traffic on. Each entry is a channel number.
>  	 */
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index d22a36f..efd30e2 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -1178,20 +1178,28 @@ static int netvsc_receive(struct net_device *ndev,
>  }
>  
>  static void netvsc_send_table(struct net_device *ndev,
> -			      const struct nvsp_message *nvmsg)
> +			      const struct nvsp_message *nvmsg,
> +			      u32 msglen)
>  {
>  	struct net_device_context *net_device_ctx = netdev_priv(ndev);
> -	u32 count, *tab;
> +	u32 count, offset, *tab;
>  	int i;
>  
>  	count = nvmsg->msg.v5_msg.send_table.count;
> +	offset = nvmsg->msg.v5_msg.send_table.offset;
> +
>  	if (count != VRSS_SEND_TAB_SIZE) {
>  		netdev_err(ndev, "Received wrong send-table size:%u\n", count);
>  		return;
>  	}
>  
> -	tab = (u32 *)((unsigned long)&nvmsg->msg.v5_msg.send_table +
> -		      nvmsg->msg.v5_msg.send_table.offset);
> +	if (offset + count * sizeof(u32) > msglen) {

Nit: I think this can overflow.

> +		netdev_err(ndev, "Received send-table offset too big:%u\n",
> +			   offset);
> +		return;
> +	}
> +
> +	tab = (void *)nvmsg + offset;

But tab is 'u32 *', doesn't compiler complain?

>  
>  	for (i = 0; i < count; i++)
>  		net_device_ctx->tx_table[i] = tab[i];
> @@ -1209,12 +1217,13 @@ static void netvsc_send_vf(struct net_device *ndev,
>  		    net_device_ctx->vf_alloc ? "added" : "removed");
>  }
>  
> -static  void netvsc_receive_inband(struct net_device *ndev,
> -				   const struct nvsp_message *nvmsg)
> +static void netvsc_receive_inband(struct net_device *ndev,
> +				  const struct nvsp_message *nvmsg,
> +				  u32 msglen)
>  {
>  	switch (nvmsg->hdr.msg_type) {
>  	case NVSP_MSG5_TYPE_SEND_INDIRECTION_TABLE:
> -		netvsc_send_table(ndev, nvmsg);
> +		netvsc_send_table(ndev, nvmsg, msglen);
>  		break;
>  
>  	case NVSP_MSG4_TYPE_SEND_VF_ASSOCIATION:
> @@ -1232,6 +1241,7 @@ static int netvsc_process_raw_pkt(struct hv_device *device,
>  {
>  	struct vmbus_channel *channel = nvchan->channel;
>  	const struct nvsp_message *nvmsg = hv_pkt_data(desc);
> +	u32 msglen = hv_pkt_datalen(desc);
>  
>  	trace_nvsp_recv(ndev, channel, nvmsg);
>  
> @@ -1247,7 +1257,7 @@ static int netvsc_process_raw_pkt(struct hv_device *device,
>  		break;
>  
>  	case VM_PKT_DATA_INBAND:
> -		netvsc_receive_inband(ndev, nvmsg);
> +		netvsc_receive_inband(ndev, nvmsg, msglen);
>  		break;
>  
>  	default:

-- 
Vitaly