netdev - Re: [net-next 10/17] fm10k: add TEB check to fm10k_gre_is

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]

Date:	Fri, 04 Dec 2015 15:03:19 -0800
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Jacob Keller <jacob.e.keller@...el.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	nhorman@...hat.com, sassmann@...hat.com, jogreene@...hat.com
Subject: Re: [net-next 10/17] fm10k: add TEB check to fm10k_gre_is_nvgre

On Thu, 2015-12-03 at 16:54 -0800, Tom Herbert wrote:
> On Thu, Dec 3, 2015 at 4:29 PM, Jeff Kirsher
> <jeffrey.t.kirsher@...el.com> wrote:
> > From: Jacob Keller <jacob.e.keller@...el.com>
> >
> > The NVGRE protocol should be run over transparent ethernet bridge
> > protocol, so we should verify this in our check whether the GRE
> tunnel
> > is NVGRE. While we're touching fm10k_main.c, update the copyright
> year.
> >
> > Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
> > Reviewed-by: Bruce Allan <bruce.w.allan@...el.com>
> > Tested-by: Krishneil Singh <krishneil.k.singh@...el.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> > ---
> >  drivers/net/ethernet/intel/fm10k/fm10k_main.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
> b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
> > index 746a198..c5f7e0d 100644
> > --- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
> > +++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
> > @@ -1,5 +1,5 @@
> >  /* Intel Ethernet Switch Host Interface Driver
> > - * Copyright(c) 2013 - 2014 Intel Corporation.
> > + * Copyright(c) 2013 - 2015 Intel Corporation.
> >   *
> >   * This program is free software; you can redistribute it and/or
> modify it
> >   * under the terms and conditions of the GNU General Public
> License,
> > @@ -708,6 +708,10 @@ static struct ethhdr
> *fm10k_gre_is_nvgre(struct sk_buff *skb)
> >         if (nvgre_hdr->flags & FM10K_NVGRE_RESERVED0_FLAGS)
> >                 return NULL;
> >
> > +       /* verify protocol is transparent Ethernet bridging */
> > +       if (nvgre_hdr->proto != htons(ETH_P_TEB))
> > +               return NULL;
> > +
> >         /* report start of ethernet header */
> >         if (nvgre_hdr->flags & NVGRE_TNI)
> >                 return (struct ethhdr *)(nvgre_hdr + 1);
> 
> I don't understand this. Just because a packet is GRE with ETH_P_TEB
> set and only using keyid does not make it a GRE packet. What happens
> if someone creates a GRE tunnel on this same host with keyid and
> starts sending packets on it?
> 
> BTW, these is a potentially similar issue in fm10k_port_is_vxlan.
> ndo_vxlan_port informs the driver of a vxlan port that may be
> received
> in a destination (presumably after the port has been bound for the
> tunnel). This says _nothing_ about source ports or the destination
> port. For instance, there is nothing that prevents an application
> from
> sending UDP packets to a "VXLAN port". If application does this, will
> it's packets be messed up by the offload misinterpreting the packets
> as VXLAN?
> 
> As for this code:
> 
>         int hlen = ip_hdrlen(skb);
> 
>         /* currently only IPv4 is supported due to hlen above */
> 
> I'm just speechless ;-)

I was waiting for Jacob to respond, but I forgot he is on sabbatical
now.  I can drop this patch from the series until someone is able to
address your questions/concerns.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)