netdev - Re: [PATCH net] net: vxlan: fix crash when interface is created with no group

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:	Wed, 19 Mar 2014 08:08:14 -0600
From:	David Stevens <dlstevens@...ibm.com>
To:	Mike Rapoport <mike.rapoport@...ellosystems.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: vxlan: fix crash when interface is created with no
 group

-----Mike Rapoport <mike.rapoport@...ellosystems.com> wrote: -----

>To: David Stevens/Beaverton/IBM@...US
>From: Mike Rapoport <mike.rapoport@...ellosystems.com>
,,,
>However, for the particular case in vxlan_rcv, checking the packet
>version seems to me semantically more correct than comparing
>default_dst
>protocol family with AF_INET or AF_INET6.

No, that's saying that the sender should determine whether
you are using IPv4 or IPv6, but when the localhost is the
sender, it'll only be using one of those.

If the default_dst is an IPv4 group address, ordinary VXLAN
wouldn't interoperate with IPv6 because the group is not an IPv6
group, but with your patch, it'll still receive and accept IPv6-encapsulated
packets. It just wouldn't send any, if all the fdb entries are also v4.

I think neither the receive packets nor the default_dst, which may
not be set, is the right way to determine this. vxlan_dev->saddr
makes more sense, but it, too, doesn't have to be set.

I'd suggest:
1) if vxlan_dev->saddr is set, use that. Any packets sent should use
          this saddr, if set, so that determines the underlay address family
          and so also what IP version you'll receive.
2) if vxlan_dev->saddr is not set, and default_dst is a multicast group,
          use that address family. For ordinary VXLAN, the group is used
          by all participants so it can't mix v4 and v6. Also, if saddr is set
          and default_dst is a multicast group, the address family should
          match.
3) if neither of those is set, then it isn't ordinary VXLAN, but rather a
         custom configuration. In that case, we should allow both, by
         default, at least. fdb entries can use both v4 and v6, so we
         should receive both.

We could also (or instead) add flags to explicitly allow or disallow v4 and/or v6,
and then, of course, enforce those flag settings for saddr, default_dst
and fdb entries, too.

                                                                  +-DLS

--
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