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:	Thu, 3 Dec 2015 16:54:01 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Jeff Kirsher <jeffrey.t.kirsher@...el.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, 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 ;-)


> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists