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 <[email protected]>
---
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..9b0532e 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 > msglen - count * sizeof(u32)) {
+ netdev_err(ndev, "Received send-table offset too big:%u\n",
+ offset);
+ return;
+ }
+
+ tab = (void *)nvmsg + offset;
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:
--
1.8.3.1
On Thu, 21 Nov 2019 13:33:40 -0800, Haiyang Zhang wrote:
> 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.
Please provide a change log at the end of the commit message when
posting new version in the future.
> Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)")
> Signed-off-by: Haiyang Zhang <[email protected]>
>
> - tab = (u32 *)((unsigned long)&nvmsg->msg.v5_msg.send_table +
> - nvmsg->msg.v5_msg.send_table.offset);
> + if (offset > msglen - count * sizeof(u32)) {
Can't this underflow now? What if msglen is small?
> + netdev_err(ndev, "Received send-table offset too big:%u\n",
> + offset);
> + return;
> + }
> +
> + tab = (void *)nvmsg + offset;
>
> for (i = 0; i < count; i++)
> net_device_ctx->tx_table[i] = tab[i];
> -----Original Message-----
> From: Jakub Kicinski <[email protected]>
> Sent: Thursday, November 21, 2019 6:05 PM
> To: Haiyang Zhang <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> KY Srinivasan <[email protected]>; Stephen Hemminger
> <[email protected]>; [email protected]; vkuznets
> <[email protected]>; [email protected]; [email protected]
> Subject: Re: [PATCH net,v2 1/2] hv_netvsc: Fix offset usage in
> netvsc_send_table()
>
> On Thu, 21 Nov 2019 13:33:40 -0800, Haiyang Zhang wrote:
> > 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.
>
> Please provide a change log at the end of the commit message when
> posting new version in the future.
Sure. Will do that in the future.
>
> > Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling
> (vRSS)")
> > Signed-off-by: Haiyang Zhang <[email protected]>
>
> >
> > - tab = (u32 *)((unsigned long)&nvmsg->msg.v5_msg.send_table +
> > - nvmsg->msg.v5_msg.send_table.offset);
> > + if (offset > msglen - count * sizeof(u32)) {
>
> Can't this underflow now? What if msglen is small?
msglen came from the vmbus container message. We trust it to be big
enough for the data region.
Thanks,
- Haiyang
On Fri, 22 Nov 2019 00:54:20 +0000, Haiyang Zhang wrote:
> > >
> > > - tab = (u32 *)((unsigned long)&nvmsg->msg.v5_msg.send_table +
> > > - nvmsg->msg.v5_msg.send_table.offset);
> > > + if (offset > msglen - count * sizeof(u32)) {
> >
> > Can't this underflow now? What if msglen is small?
> msglen came from the vmbus container message. We trust it to be big
> enough for the data region.
Ok, it looked like it was read from some descriptor which could
potentially be controlled by "the other side" but I trust your
judgement :)
Both patches LGTM, then.