All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pravin Shelar <pshelar@nicira.com>
To: Mike Rapoport <mike.rapoport@ravellosystems.com>
Cc: David Stevens <dlstevens@us.ibm.com>,
	David Miller <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net] net: vxlan: fix crash when interface is created with no group
Date: Sun, 23 Mar 2014 22:09:33 -0700	[thread overview]
Message-ID: <CALnjE+r9kXBjpDdm07pbo6NSd37sgJzn9S8d7KZ188Zdmoc6Ng@mail.gmail.com> (raw)
In-Reply-To: <CAF1J0HOd9D1t4hxjMe7Muad71o_pgKQsn3jLxqR5ZFPpj2_Nrw@mail.gmail.com>

On Sun, Mar 23, 2014 at 2:27 AM, Mike Rapoport
<mike.rapoport@ravellosystems.com> wrote:
> On Fri, Mar 21, 2014 at 05:22:06AM -0600, David Stevens wrote:
>> -----Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: -----
>>
>> >Checking skb->protocol will drop ARP requests. What about using
>> >ip_hdr(skb)->version?
>>
>> 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.
>>
>>                                          +-DLS
>>
>
> I beleive I've groked what's going on in vxlan_udp_encap_recv and
> vxlan_rcv. There are actually two unrelated problems:
>
> 1) When the vxlan is configured with IPv4 group it crashes when it
> starts to receive IPv6 IGMP packets encapsulated into IPv4 vxlan
> packets. This happens because when ipv6_rcv handles the inner packet,
> the skb->dst still refernces outer IPv4 info. The very old vxlan code
> had skb_dst_drop call in vxlan_udp_encap_recv, which was removed when
> vxlan was refactored to use iptunnel_pull_header (commit
> 7ce04758279514ca1d8ebfe322508a4a430fe2c8: "vxlan: Restructure vxlan
> receive"). The iptunnel_pull_header called skb_dst_drop until recent
> commit 10ddceb22bab11dab10ba645c7df2e4a8e7a5db5 ("ip_tunnel:multicast
> process cause panic due to skb->_skb_refdst NULL pointer").
> The simplest fix, I think, would be to restore call to skb_dst_drop in
> vxlan_udp_encap_recv.
>
iptunnel_pull() is used in multiple tunnel implementation, therefore
we need drop dst in that function.
I send out fix : http://marc.info/?l=linux-netdev&m=139563761515707

  parent reply	other threads:[~2014-03-24  5:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-17 11:17 [PATCH net] net: vxlan: fix crash when interface is created with no group Mike Rapoport
2014-03-17 16:34 ` Stephen Hemminger
2014-03-18 15:10 ` Or Gerlitz
2014-03-18 15:51   ` Mike Rapoport
2014-03-19  3:20     ` David Miller
2014-03-19  6:56       ` Mike Rapoport
2014-03-18 16:41 ` Cong Wang
2014-03-18 16:55 ` David Stevens
2014-03-18 18:07   ` Cong Wang
2014-03-19  7:14   ` Mike Rapoport
2014-03-19 19:46     ` David Miller
2014-03-19 19:52       ` Mike Rapoport
2014-03-19 22:29         ` David Miller
2014-03-19 20:28     ` David Stevens
2014-03-20  3:40       ` David Miller
2014-03-19 14:08   ` David Stevens
2014-03-19 14:32     ` Mike Rapoport
2014-03-19 14:40     ` David Stevens
2014-03-20 20:02 ` David Miller
2014-03-21  5:06   ` Mike Rapoport
2014-03-20 20:47 ` David Stevens
2014-03-21 10:22   ` Mike Rapoport
2014-03-21 11:22   ` David Stevens
2014-03-21 15:31     ` Mike Rapoport
2014-03-23  9:27     ` Mike Rapoport
2014-03-23 14:43       ` Or Gerlitz
2014-03-26  0:53         ` David Miller
2014-03-26  9:47           ` Mike Rapoport
2014-03-26 14:47           ` David Stevens
2014-03-26 17:50             ` Mike Rapoport
2014-03-27 20:20               ` Cong Wang
2014-03-28  9:05                 ` Mike Rapoport
2014-03-29  8:29           ` Mike Rapoport
2014-03-31 20:18             ` David Miller
2014-03-24  5:09       ` Pravin Shelar [this message]
2014-04-01  6:23 Mike Rapoport
2014-04-01 19:22 ` Cong Wang
2014-04-02  5:51   ` Mike Rapoport
2014-04-03 15:19 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALnjE+r9kXBjpDdm07pbo6NSd37sgJzn9S8d7KZ188Zdmoc6Ng@mail.gmail.com \
    --to=pshelar@nicira.com \
    --cc=davem@davemloft.net \
    --cc=dlstevens@us.ibm.com \
    --cc=mike.rapoport@ravellosystems.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.