netdev - Re: [PATCH net-next] vxlan: drop packets from invalid src-address

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]

Message-ID: <c4f2c217-b2bd-4716-be17-3c6097873061@david-bauer.net>
Date: Wed, 3 Apr 2024 19:14:14 +0200
From: David Bauer <mail@...id-bauer.net>
To: Ido Schimmel <idosch@...dia.com>, Simon Horman <horms@...nel.org>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, amcohen@...dia.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] vxlan: drop packets from invalid src-address

Hi Ido,

On 4/3/24 14:45, Ido Schimmel wrote:
> On Tue, Apr 02, 2024 at 07:08:48PM +0100, Simon Horman wrote:
>> On Sun, Mar 31, 2024 at 11:14:34PM +0200, David Bauer wrote:
>>> The VXLAN driver currently does not check if the inner layer2
>>> source-address is valid.
>>>
>>> In case source-address snooping/learning is enabled, a entry in the FDB
>>> for the invalid address is created with the layer3 address of the tunnel
>>> endpoint.
>>>
>>> If the frame happens to have a non-unicast address set, all this
>>> non-unicast traffic is subsequently not flooded to the tunnel network
>>> but sent to the learnt host in the FDB. To make matters worse, this FDB
>>> entry does not expire.
>>>
>>> Apply the same filtering for packets as it is done for bridges. This not
>>> only drops these invalid packets but avoids them from being learnt into
>>> the FDB.
>>>
>>> Suggested-by: Ido Schimmel <idosch@...dia.com>
>>> Signed-off-by: David Bauer <mail@...id-bauer.net>
>>
>> Hi David and Ido,
>>
>> I wonder if this is an appropriate candidate for 'net', with a Fixes tag.
>> It does seem to address a user-visible problem.
> 
> I'm OK with targeting the patch at 'net'. Looking at git history, the
> issue seems to be present since initial submission so Fixes tag should
> be:
> 
> Fixes: d342894c5d2f ("vxlan: virtual extensible lan")
> 
> David, can you please re-submit with "[PATCH net]" prefix and the above
> tag?

I can take care of that. Thanks for analyzing the situation.

One thing i still have in my head when looking at this:

 From my understanding, when i manage to send out such a packet from e.g. a
VM connected to a vxlan overlay network and manage to send out such malformed
packet, this would allow me to break the overlay network created with vxlan doesn't it?

Can you comment on my assumption there? I assume you have a better understanding of
the inner workings of the vxlan protocol.

Best
David

> 
> Thanks