[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF1J0HPTV+XHORSLy3H-6-tBx91F0+L7UhnZd7YsGZCSEQad2Q@mail.gmail.com>
Date: Fri, 21 Mar 2014 17:31:55 +0200
From: Mike Rapoport <mike.rapoport@...ellosystems.com>
To: David Stevens <dlstevens@...ibm.com>
Cc: David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: vxlan: fix crash when interface is created with
no group
On Fri, Mar 21, 2014 at 1:22 PM, David Stevens <dlstevens@...ibm.com> wrote:
>
> -----Mike Rapoport <mike.rapoport@...ellosystems.com> wrote: -----
>
> Mike, ip_hdr() here is the outer packet, so it's got to be a UDP packet--
> we just don't know if it's UDP/IP or UDP/IPv6 when it is bound to INADDR_ANY,
> since both can be delivered. It could use version in this case, because
> both possible protocols have version in the same place, but I think it's
> more correct to use the MAC layer protocol rather than relying on the
> fact that IPv4 and IPv6 have "version" in the same spot. "It could be ARP"
> would be the argument for NOT using the version in places where it really
> could be ARP, even though that isn't the case here.
>
> vxlan_rcv() is only called for VXLAN encapsulated packets sent to the bound
> UDP port.
>
> So, if "vs->family" holds the one we want to support, we can't just blindly
> assume the received packet is IPv4, for example, and start accessing
> IPv4 fields, because it could be an IPv6 packet. We have to check the
> packet type too. And if it's not the one we bound to, drop it.
>
> That's what the code snippet I outlined is trying to do.
>
David,
I've tried your snippet with IPv4 and I've got all ARP replies
dropped. And if I enable IPv6 I still get crushes in ipv6_rcv.
It seems to me that at the time vxlan_rcv gets outer IP header, the
SKB contains mixed information of outer and inner packets.
I'll continue to look into it.
+-DLS
>
>
>
--
Sincerely yours,
Mike.
--
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