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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Mar 2014 16:32:17 +0200
From:	Mike Rapoport <mike.rapoport@...ellosystems.com>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: vxlan: fix crash when interface is created with
 no group

On Wed, Mar 19, 2014 at 4:08 PM, David Stevens <dlstevens@...ibm.com> wrote:
>
>
> -----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'm not really familiar with v4 and v6 interoperability, but the
vxlan_socket_create will create v6 socket only if IPv6 is explicitly
requested.
Would it be possible to receive IPv6-encapsulated packets from IPv4 socket?

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



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