netdev - VxLAN learning creating broadcast FDB entry

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-next>] [day] [month] [year] [list]

Message-ID: <15ee0cc7-9252-466b-8ce7-5225d605dde8@david-bauer.net>
Date: Tue, 20 Feb 2024 19:33:54 +0100
From: David Bauer <mail@...id-bauer.net>
To: Ido Schimmel <idosch@...dia.com>, Amit Cohen <amcohen@...dia.com>
Cc: netdev@...r.kernel.org
Subject: VxLAN learning creating broadcast FDB entry

Hi,

we are using a VxLAN overlay Network to encapsulate batman-adv Layer 2 
Routing. This distance-vector protocol relies on originator messages 
broadcasted to all adjacent nodes in a fixed interval.

Over the course of the last couple weeks, I've discovered the nodes of 
this network to lose connection to all adjacent nodes except for one, 
which retained connectivity to all the others.

So there's a Node A which has connection to nodes [B,C,D] but [B,C,D] 
have no connection to each other, despite being in the same Layer 2 
network which contains the Layer2 Domain encapsulated in VxLAN.

After some digging, I've found out the VxLAN forwarding database on 
nodes [B,C,D] contains an entry for the broadcast address of Node A 
while Node A does not contain this entry:

$ bridge fdb show dev vx_mesh_other | grep dst
00:00:00:00:00:00 dst ff02::15c via eth0 self permanent
72:de:3c:0b:30:5c dst fe80::70de:3cff:fe0b:305c via eth0 self
66:e8:61:a3:e9:ec dst fe80::64e8:61ff:fea3:e9ec via eth0 self
ff:ff:ff:ff:ff:ff dst fe80::dc12:d5ff:fe33:e194 via eth0 self
fa:64:ce:3e:7b:24 dst fe80::f864:ceff:fe3e:7b24 via eth0 self
[...]

I've looked into the VxLAN code and discovered the snooping code creates 
FDB entries regardless whether the source-address read is a multicast 
address.

When reading the specification in RFC7348, chapter 4 suggests

 > Here, the association of VM's MAC to VTEP's IP address
 > is discovered via source-address learning.  Multicast
 > is used for carrying unknown destination, broadcast,
 > and multicast frames.

I understand this as multicast addresses should not be learned. However, 
by sending a VxLAN frame which contains the broadcast address as the 
encapsulated source-address to a Linux machine, the Kernel creates an 
entry for the broadcast address and the IPv6 source-address the VxLAN 
packet was encapsulated in.

This subsequently breaks broadcast operation within the VxLAN with all 
broadcast traffic being directed to a single node. So a node within the 
overlay network can break said network this way.

Is this behavior of the Linux kernel intended and in accordance with the 
specification or shall we avoid learning group Ethernet addresses in the 
FDB?

I've applied a patch which avoids learning such addresses in vxlan_snoop 
and it mitigates this behavior for me. Shall i send such a patch 
upstream? [0][1]

I see vxlan_fdb_update_create already disallows creating such an entry, 
but only if NLM_F_REPLACE is set, which it is not in the call-path from 
vxlan_snoop.

[0] https://github.com/freifunk-gluon/gluon/issues/3191
[1] https://github.com/freifunk-gluon/gluon/pull/3192

Best
David